Skip to main content

Sprint historical velocity in planning and capacity calculation

Last post 02:19 pm May 30, 2024 by Pierre Pienaar
6 replies
10:20 pm May 21, 2024


I will be asking a dilema which I have been having for some time now. This is related to historical velocity for planning and capacity relatioship

I will come with a simple example:

The full capacity of the team is 400 hours

Sprint 1: 28 story points (with one team member on vacation, 360 hours)
Sprint 2: 30 story points (with a few unexpected meetings, 380 hours)
Sprint 3: 32 story points (All members present, 400 hours)

So historical velocity (28 + 30 + 32) /3 = 30 points. 

then next sprint some people is off and unplanned meetings, so 360hs of capacity, this is 360/400 , 90% of the sprint capacity

Then a practical suggestion to plan for the new sprint velocity would be 30 points x 0,9 = 27 points 

Some people would say historical velocity inherently includes all past variations and inefficiencies.
This means the 30 story points per sprint already account for the team's realistic performance, including time lost to meetings, vacations, and other interruptions so the calculation is more correct since it less likely lead to overcommittment and considers innefiencies and all real factors. 

But on the other hand should be more or less precise to adjust the teams historical velocity as it if would have had a full capacity? 

So Average Historical Capacity: 

(360+380+400)/3=380 hours.
Adjust Historical Velocity to Full Capacity:30story points×(400/380)=32 story points

Then next sprint some people is off and unplanned meetings, so 360hs of capacity, this is 360/400 , 90% of the sprint capacity

Then the plan for the new sprint velocity to suggest would be 32 points x 0,9 = 28 points 

I have read articles on this which tell about de decrease on the historical velocity based on the present team capacity in planning, but no one clarifies what to do with the historical velocity if to leave it as it is or should be adjusted to full capacity as well? 

Approach 1 seems less complex, but approach 2 maybe is more precise or is something I am missing? 

How do you normally handle this relationship of average historical velocity and planning next sprint with descrease in capacity? 

Thanks in advance!

10:50 pm May 21, 2024

After doing this since 2007, my advice is to keep it simple and take the average velocity of the past three Sprints. Many consider velocity and capacity the same thing. Try not counting team capacity in hours for a few Sprints and see if anything changes for the better or worse. My teams dropped adding up their hours over a decade ago. 

Trying to be precise with complex work (i.e. where there is more unknown than known) is like a cat chasing its tail. Story points are simply best guesses. In most Sprints, your plan will never be perfect, but that's okay. There is a lot that can go wrong after the Sprint is planned (e.g. people get sick, people take an unplanned vacation day, work gets added and removed from the Sprint, etc.). But you have the Daily Scrum to replan every day. The Sprint goal provides focus and flexibility for the unknowns.

Focusing on the outcomes, such as meeting the Sprint Goal and delivering a valuable increment, is much more important than getting velocity correct and having the perfect plan. In fact would anyone care if your velocity calculation was perfect yet no one wanted to use what you built?

Embrace uncertainty, get comfortable with uncertainty, and use change to your advantage. That's what agility is about. 

10:59 pm May 21, 2024

I think you're going about this the wrong way. You're starting from velocity, likely in an attempt to fill the Sprint with work, instead of starting from a goal and checking the effort needed to complete the goal instead. The word "goal" or "Sprint Goal" doesn't appear anywhere in your discussion of planning.

You know that you can likely get somewhere between 27 and 32 points of work done, depending on exactly how you calculate capacity. But what goal do you want to achieve? And how much effort will it take to accomplish that goal?

If you can craft a Sprint Goal and then select the Product Backlog Items that the team believes must be Done to achieve that Sprint Goal, can you figure out the size of those items? If so, is it more than 32? If so, you almost certainly need to replan, likely by revisiting your Sprint Goal. If it's somewhere between 27 and 32, there's a risk, but you can monitor. If it's less than 27, then you may be fine.

Regardless, even after you achieve your Sprint Goal, you can still pull Product Backlog Items from the Product Backlog. By the end of the Sprint, you'll be able to count the amount of work that the team got to Done and use this in future historical calculations of velocity. But I'd continue to recommend the same approach: craft a Sprint Goal, check effort against capacity, replan until a goal fits into capacity.

As far as calculating capacity, I'd recommend planning at 75-85% of the average of the last three Sprints. In your particular case, the rolling average is 30, so I'd plan on somewhere between 22 and 26 for the goal, and then be ready to pull additional work if time permits. However, the percentage tends to be a function of the risk tolerance of the organization. An organization that prefers to be more conservative and create goals that are more likely to be attainable would likely be closer to 75-80%. A more risk tolerant organization that is willing to reach and fail to achieve a goal may target 85% or even the 90% that you propose. I wouldn't recommend going above 90%, just to leave room for the unexpected.

11:15 pm May 21, 2024

Scrum is aimed at complex challenges and people themselves are complex. If it was possible to manage things by the numbers, you wouldn't need Scrum at all.

Capacity is not a science and we are not story point accountants. Risk and uncertainty are endemic, so encourage the Developers just to get their arms around how much work they think they can take on each Sprint. Everything else reduces to value delivery and empirical process control. Capacity is less important than the contingency the Developers reckon they might need, roughly considering the variables they know about, to meet their Sprint Goal commitment.

12:30 pm May 22, 2024

The whole idea of using Story Point is to relatively estimate because we can't accurately plan each task in hours or man days. Matching the history of work done may not also help to plan the future work because lot of factors will be different. If the team spend time in detailing the estimation, they may loose the focus in doing what is valuable. 

10:02 am May 23, 2024

Maybe you are overthinking it, I have had quite some success taking the historical velocity as a conversation starter to check if the team can achieve their sprint goal or to help them not to overcommit (we all know that PO). You might not want to put that much emphasis into these metrics and become overbearing. 

There might be something more to it depending on how is the company culture and how mature is the team. For example if they are misusing Velocity outside of the team to measure performance or if the team is not mature enough to speak openly.

02:19 pm May 30, 2024

I agree with the other comments the approach is to complicated, and story point estimations are just an estimate, don't try to get it accurate to the story point.

A slightly different focus. It seems the team is presented with a story point number that they need to plan against. Rather allow the team to self-manage and let the team decide what they can pull in and what is achievable. Define an achievable goal with the team, and let the team decide how best to reach the goal. The team should decided how many items can be pulled from the backlog and what is an achievable sprint plan. Start with a goal and pull items in, and use the velocity number only as a rough indicator of an upper limit, to prevent over planning. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.