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?

  • One thing you are missing, which is also always the big unknown, is how the requirements will change after each sprint review. That is one of the main reasons why agile methods (like scrum) don't pretend to give certainty about the planning on the long term. Commented Oct 12, 2018 at 17:13
  • Interesting. Can you give me an example, @BartvanIngenSchenau? It's my understanding that a utility of the Sprint Planning event is to take requirement changes into account. This event is timeboxed, therefor a constant. The Daily Scrum is also a replanning event utilized to take changing requirements into account as they move a team towards its Sprint Goal. The Daily Scrum is also a timeboxed event. Trying to wrap my head around how a team could use changing requirements to forecast capacity when they're already accounted for in timeboxed events. Commented Oct 12, 2018 at 17:20
  • Maybe I misunderstood you. I got the impression you wanted to do a planning for the work to come in the next months. The Sprint Planning is just about the next iteration (i.e. four weeks at the most) and the Daily Scrum is about the upcoming day. Requirements are expected to be relatively fixed during an iteration. Commented Oct 12, 2018 at 18:03
  • @BartvanIngenSchenau, that's good feedback. I've edited the question to be more explicit about capacity being an input into a single sprint planning meeting. Commented Oct 12, 2018 at 18:06
  • The point of capacity planning isn't higher utilization; it's simply ensuring you don't take on work that is likely to exceed the Sprint time box or endanger the Sprint Goal. So, how often are you currently meeting your Sprint Goals?
    – Todd A. Jacobs
    Commented Oct 15, 2018 at 4:20

2 Answers 2


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.

  • 1
    Thanks, Daniel. Luckily our team is coached on the fact that our sprint goals are not married to any lagging indicators such as velocity, rather they focus on functionality that can be forecasted and potentially-releasable. We use capacity to understand what's a conservative sprint goal and what's a stretch goal before planning. Appreciate the feedback and something I'll definitely bring up for team discussion. Commented Oct 12, 2018 at 17:37
  • Awesome! Glad to hear it!
    – Daniel
    Commented Oct 12, 2018 at 17:50

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.


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).

  • Thanks for the feedback. The question was scoped to capacity, not Sprint Planning in its entirety. The Definition of Done (DoD) is thankfully already visualized during planning and the team is empowered to bring in as much or as little as it sees fit. Team members are empowered to forecast their individual expertise to a particular item during refinement before planning. This derivative is in-line with Scrum.org's scaled Nexus framework as to minimize dependencies. The capacity is simply a number the team can use to help answer the what? and how? of planning while accounting for unplanned work Commented Oct 12, 2018 at 18:47
  • Indeed... my point is that capacity is a measurement - so what are you measuring and how do you measure it? If you are measuring person-hours available in a Sprint, then your measurement is meaningless since (presumably) you are applying Scrum to complex product development. In the complexity space, you cannot think of capacity as a linear relation with time. Commented Oct 12, 2018 at 19:05
  • So, to clarify my conclusion, you cannot make a distinction between "capacity" and "Sprint Planning" because Sprint Planning is exactly the team's determination of capacity against the complexity of the problem space it is given. In other words, capacity will vary Sprint-to-Sprint based on the items in the Product Backlog and the skill/wisdom of each team member (which hopefully increases each Sprint). Commented Oct 12, 2018 at 19:05
  • Finally, the DoD is not something that should be visualized during Sprint Planning. The DoD is independent of the PBIs on the backlog and should only increase (improve) Sprint to Sprint. For example, if unit testing is part of the DoD in Sprint N, then it should always be part of the DoD for Sprint N+1, N+2, etc. Commented Oct 12, 2018 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.