Let's suppose that a Scrum team have a velocity of 50 Story Points per a Sprint. During a Sprint Planning Meeting they add some Stories to the Sprint Backlog until the total sum of these Stories gets equal to 50. I suppose that Scrum teams shouldn't reserve additional time for unpredictable work (reinsurance) when making estimations. Doing so they're increasing the chances that they're guaranteed to complete all the work planned. But this reduces the team's performance.

This means that the probability that they will have time to complete all the work is about 50%. Do you agree with this?

As Scrum Masters we can make some guesses about the team based on the rate of the successful Sprints of the particular team:

  • if the team almost always completes all the work planned for a Sprint then this probably means that the team just reserves additional time and, therefore, underperforms
  • a team that strives to do as much as they're able to do will inevitably have only about 50% of successful Sprints (some Sprints get completed earlier, some Sprints get failed due to unpredictable work)
  • 3
    Are your Product and Sprint Goals being met? Then you're not underperforming. You keep bringing up utilization in various ways in multiple questions, but that's not the correct metric for determining how much value the Scrum Team is delivering over time.
    – Todd A. Jacobs
    Dec 5, 2020 at 18:21
  • @ToddA.Jacobs A customer pays his money for every hour of team working. And the budget for a project is limited.
    – Daniel
    Dec 5, 2020 at 20:02
  • 2
    No, that's incorrect. A customer pays per the terms of your contract, and the money paid is legally a form of consideration for the service or product provided under the terms of the agreement. If your contracting process is based on non-agile metrics (e.g. utilization rates), then you have a contractual mismatch with your process. There are plenty of other Q&As here about how to properly structure agile contracts, and the importance of collaborating with the customer rather than billing for person-hours or effort rather than for iterations or value.
    – Todd A. Jacobs
    Dec 5, 2020 at 20:20
  • Does the velocity of 50 story points achieved in previous sprints also include unexpected work? If there's some amount of unscheduled work in every Sprint, that might already be included in the velocity.
    – Llewellyn
    Dec 6, 2020 at 15:19
  • @ToddA.Jacobs What Q&A do you mean, can you provide an example?
    – Daniel
    Dec 6, 2020 at 16:39

2 Answers 2


Velocity is a guide the team uses to help them work out the capacity of a sprint.

As a Scrum Master the conversation would typically go like this:

"Our velocity is currently 50 points. Jane, I know you are out on holiday this week, so that is going to knock off some capacity. Frank, I think you are on a training course as well, right? OK, shall we go for 40 points? We have missed completing all the planned work in the sprint for a couple of sprints now, shall we bring it down a bit more? Maybe 35 points? We can have a few refined stories ready to go at the top of the backlog in case this turns out to be low."


If we were to assume that the average velocity of the Scrum Team was 50 Story Points over some recent number of Sprints (usually the last 3-5 Sprints, in my experience), then you could apply Yesterday's Weather and plan on your next Sprint having a velocity of close to 50 Story Points. However, this does make some key assumptions. One assumption is that the capacity of the previous Sprints and the upcoming Sprint are close. Another assumption is that process improvement experiments are being neglected in velocity calculations. However, it's a fairly quick and easy calculation that the team can do on-the-fly to figure out if they are planning on a reasonable amount of work for a Sprint.

As far as reserving additional time for unpredictable work, empiricism also comes into play. Empiricism is about making decisions based on knowledge and observations obtained in the past. How often does the team take on unplanned work in the course of the Sprint? What is the typical size or effort associated with this unplanned work? How tolerant is the organization of deviations from the planned work? The answers to these questions will determine if you should load your Sprint to capacity. I always prefer to leave a buffer of about 20-30% to account for unplanned work and unplanned absences in the team. If I obtained a velocity of 50 Story Points by applying Yesterday's Weather, I'd plan on aligning my Sprint Goal to no more than about 35-40 Story Points. Work to fill the remaining capacity could be identified at Sprint Planning, understanding that the work associated with the Sprint Goal is the most important to have complete by the Sprint Review.

I don't necessarily agree that filling a Sprint to maximum capacity means that the team has a 50% probability of completing all the work. It's neglecting the likelihood of changes to capacity, the necessary variability in estimates, and the discovery of more or less work as the Sprint goes on, among other things. I'm not sure if I could quantify the probability of work completion beyond "likely" that the team will perform similar to the recent past. A process improvement could lead to improved performance or perhaps have a negative effect. A team member could need an unplanned 2 or 3 days out of work to deal with a life event. Perhaps some tooling or infrastructure issue prevents one or more people from carrying out their work. It's hard to quantify these, but more details about the organization will help understand what has happened in the past.

I'd also point out that all of this is built around the output of work instead of helping customers and users achieving the desired outcome. The Sprint's purpose is not to complete a certain number of Story Points but to deliver value to the end-user. Story Points aren't a measure of value. Completing a single 2 or 3 Story Point unit of work could be immensely valuable and entirely worth funding the entire Sprint. Focusing on creating and achieving a valuable Sprint Goal, ensuring that the work needed to achieve that goal can likely be done within the Sprint. Focusing the team's effort on the goal will have bigger payoffs in the long run than counting the delivery of Story Points.

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.