This term is not frequently used in Agile, but plays a very important role in Agile planning, estimations, and ability to complete Sprint Commitments. Utilization Ratio is used to calculate Team’s capacity – the amount of work that the Team can confidently complete during the Sprint. You may say “Why? Don’t we have Velocity for that?” Good question. Let’s explain.

Velocity is a measure of the amount of work the Team was able to successfully complete during each Sprint. Over time, if the Team follows the same estimation methodology for the User Stories and is consistent with maintaining estimation relativity to a baseline story, the average Velocity will provide the Team with a relatively predictable estimated workload the Team can take on and complete during the Sprint. This is typically done in some units of WAGs ( typically called a wild a** guess ). In Agile, its generally preferred to call these guesses in “Story Points”.

Alistair Cockburn, one of the creators of Agile Manifesto recently tweeted how Velocity came to life in Agile as a method of Team work volume predictability called “Yesterday’s Weather”, which was adopted to help Teams avoid overcommitting.

The challenge, however, is that each Sprint will naturally vary. For example, 2 Team Members from a 7 person Team are on vacation for an entire week next Sprint. Does that impact the Velocity? Absolutely, the Team can no longer commit to getting the same number of Story Points done in the same period of time. Figuring out the amount of work the Team can commit to, means calculating the Team’s capacity for each Sprint. Is the Team in full force? Will there be vacations? Holidays? Will there be business travel? Events? Corporate All Hands getaways? Basically, are there any events that reduce the amount of work time available to the Team during the Sprint as compared to previous Sprints.

With this thought, a new term evolved called Team Capacity – an amount of Time available to the Team to work on the Sprint goal.

Calculating Capacity

Now, you may think that once you can figure out an approximate delta in Velocity that can be targeted during the upcoming Sprint, that should suffice. However, that would be a mistake. The challenge with calculating capacity based on Story Points is that it’s not very accurate. Or we should probably say, not accurate at all. Why?

The Story Points by definition are already guestimates, and it’s really hard to calculate correctly the impact on the capacity that, for example, will be caused if say the most senior engineer on the team goes on a long vacation. 

Hence, there are two alternatives. Ignore the fact that Capacity in Points are inaccurate and just wing it. Or, figure out a better way to calculate Team’s upcoming Sprint Capacity.

Winging It

First, lets look at the impact of completely ignoring capacity variance. This approach means taking pretty much a wild guess. Or maybe not even calculating capacity at all, and just picking up the same number of Story Points as previous Sprint despite knowing that the Sprint will have a smaller number of working days.

We won’t say it won’t work. It will. But only enough to show Team unable to deliver on their goals and constantly having to reiterate the conditions of each Sprint during Sprint Review. This environment may lead the Team toward a defensive posture and ruin the motivation to deliver on the goals. So, while possible, it is definitely not the best approach. The best approach is to put the Team on the trajectory of success by providing them the tools to set appropriate and attainable goals Sprint to Sprint.

Using Utilization Ratio

The most recommended approach for calculating Team’s precise capacity actually stems from Story decomposition. How does it work? 

Before the Sprint starts, the Team decomposes every committed Story in the Sprint Backlog into small granular Tasks. The nature is to ask the question “What do we have to complete to call this Story done?” Answering this question recurrently helps come up with a quick and easy list.

This type of decomposition doesn’t take long and usually takes place during Sprint Kickoff. Each Story in the Sprint is broken down into small tasks. And each story being small enough, can be quickly estimated in hours. We recommend any task to be 16 hours or less, and to introduce a rule that if someone still comes up with a task estimate exceeding 24 hours, the task must automatically be broken down even further into smaller tasks. Exception to the rule is Spikes that are time boxed. 

The sum of all hourly estimates is added to present an optimistic projection of hours needed to complete the work. Then, we calculate the available hours of work during each Sprint by calculating:

( Days in Sprint * Team Members ) – ( Days * Team Members Not Available ) = Working Days

Working Days * 8 hours = Total Number of Work hours in a Sprint

Now, this is where Utilization Ratio is golden. The main problem in the formula above is the 8 hours expectations. While every full time member of the team is expected to work at least 8 hours per day on meeting Sprint commitments, that’s a mistake. Engineering teams are burdened with meetings, support cases, design work, help to other team members, corporate training and so much more that consumes a significant amount of daily time. This ratio of work hours committed towards Sprint Goals vs total available hours is called Utilization Ratio.

Hours of Work toward Sprint Commitments / Total Team Hours each Sprint = Utilization Ratio

As a matter of fact, studies have shown that the best teams in the world can only contribute up to 75% of work towards Sprint commitments. Most teams operate largely at 65% Utilization Ratio. This has a significant impact on Team’s projections and the ability to deliver. For example, an 8 hour task will take more than a day to complete, as opposed to us automatically assuming that it can be done in a single 8 hour day.

You may say “OK, this is great for calculating hours and may work for those teams that prefer this approach, but we track things in Velocity. Doesn’t Velocity automatically adjust based on activities such as meetings, events, etc?” Yes, but not quite.

Let’s Put It All Together

Let’s imagine that our Team planned the next Sprint and used Velocity to guide the initial set of commitments. Then, once our Team decomposed the Stories and calculated available hours and factored in Utilization Ratio we observed that the Team’s Sprint Capacity is less than the sum of all task hours. Meaning, the Team has picked up more work than is available within the Sprint. 

In this example, our Team believes the work goal is attainable but is overcommitting if we apply the capacity as sanity check. Our Team is taking more hours than is available even before it accounted for undiscovered work within the Sprint. And if such is observed, it is a good practice to drop commitments and reduce the scope and commit to lesser Story Point Velocity for the upcoming Sprint.

It works the other way as well. If our Team observes that the total number of hours for all Stories planned by Velocity are taking much less time than available, chances are that our Story Point estimates somehow lost accuracy. The Team has room to commit to more work. 

This approach brings a new dimension to Team’s confidence in its ability to deliver on its commitments. It’s no longer subjective. It is supported by a mathematical model that increases the accuracy of projections, maintaining a healthy balance in Team’s workload pressure and the ability to deliver.

Estimating purely on Velocity is like projecting the same investment returns – “past performance does not guarantee future results.” The estimation approach based on capacity is significantly more accurate. And for Team to be genuinely Agile, estimation accuracy is one of the biggest and most important metrics. Without accurate estimates ( which are difficult to do right ), the ability to adapt, improve, commit and deliver becomes even more difficult. And if Agility is defined as the “ability to change direction quickly and with ease”, the lack of quality estimates limit the Team’s ability to make quality decisions.

Blog Project Simple