Measuring team capacity for upcoming sprint on a Scrum Team

Question

As a Scrum Master, I have been tasked with helping the team understand its capacity for an upcoming sprint. This capacity, along with the product backlog, the latest increment, and past team performance are all artifacts I need before we dive into Sprint Planning.

As of today, I use the following to calculate team capacity:

Known outages (vacation, training, company holidays, conferences, etc.)

a conservative 10% of full sprint length time for refinement

Scrum events (Planning time itself, Daily Scrum, Sprint Review, and Sprint Retro)

My question: what am I missing? What else should I be taking into account to help my team understand its capacity for forecasting future work?

Answer 1

One other thing you could look at is past sprint variability. If, in the last 5 sprints (assuming nothing like a holiday is really skewing your numbers) you have an average of 35 points and your high and low are 39 and 33, you're probably fine with the things you mentioned. On the other hand, if you have that same average and your high and low are 45 and 20, anything over 20 for next sprint carries more and more significant risk.

In addition, remember that these estimate are good-enough numbers. They are intentionally somewhat inaccurate and imprecise. The reason we want to look at our past capacity is not to fill it, but to pick a target product increment (sprint goal) that seems to reasonably fit in that capacity. If you find the team or organization putting too much effort into "correct" estimates or capacity measures, this has probably gotten flipped around and you lose much of the value of the Scrum framework.

Answer 2

There are two obvious missing items from your list of considerations: the definition of "done" and the team's own opinion itself of its capacity. There is a simple exercise you can use to help the team with this that I have called "commitment based Sprint planning". It goes as follows:

First, present the team with the other information you mentioned in your question so that everyone is aware of that data.

Second, visually establish/update the definition of "done". This may take quite a long time if the team has not previously made this explicit. Examples of things in the definition of "done" include technical quality, bureaucratic activities, release activities, user and business quality, security, documentation, etc.

Third, repeat the following steps until any member of the team shows uncertainty either by voice or by facial expression:

1. Present the team with the next Product Backlog Item (PBI). If this is the first round through these steps then this is the PBI that is at the top of the backlog.
2. Give the team a short time (usually 5 minutes max) to discuss the meaning and implementation of the PBI and ask the Product Owner clarifying questions.
3. Ask the team: can you commit to completing this item (and any already agreed) in the current Sprint?
4. If every member agrees, then the item is added to the list of items in the team's capacity for the Sprint. If any member disagrees or shows significant uncertainty, then stop. NOTE: team members should not be pressured to agree - the decision to accept a PBI must be unanimous!

Finally, look at the PBIs that are put into the agreed pile and do a sanity check with the team: given the definition of "done", can the team unanimously agree that all of these items can be completed by the end of the Sprint? If the answer is still "yes" then this is the capacity of the team. If there is uncertainty, then the team works to split some of the larger PBIs into smaller ones and removes small amounts of work until there is unanimous agreement.

NOTE: At no point in the discussion should individual team members be volunteering for specific pieces of work, nor should estimating be done based on individual availability.

Conclusion

The word "capacity" is often thought of as person-hours. This is a false understanding of capacity when one is working in a complex problem environment. Instead, capacity can be thought of as the team's ability to apply its expertise to specific problems. The framework I have described above does not give you a "person-hours" measurement. Instead, it gives you a direct measure of the team's ability to apply its expertise to a specific set of problems (the PBIs) in a specific amount of time (the Sprint).