Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Why should the sprint forecast be accurate?

Last post 07:18 pm October 19, 2022 by Thomas Owens
2 replies
03:45 am October 19, 2022

Hello team, When planning what work to accept for the sprint the team strives to accept the right amount based on estimated sizes, availability, past velocity etc... but it's always difficult. I have observed 2 scenarios playing out;

  • Most of the time they accept too much, knowing that it will be a stretch. They rarely complete all these tickets but they are happy they don't run out of work. The downside here is that at the next sprint planning there can be lots of partial tickets on the go making that subsequent sprint forecasting even more challenging.
  • Sometimes they try and be more accurate and acknowledge that if they finish their work early they can always bring more into the sprint. They have previously worried about this messing up the burndown chart but I think I've got it through that this does not matter. 

What I am questioning now is why should we strive for the sprint forecast be accurate? My gut is saying it should be accurate but I'm struggling to find the argument to back that up! Any thoughts?


06:05 am October 19, 2022

Why should the sprint forecast be accurate?

The Sprint Backlog is a forecast of the work needed to meet the Sprint Goal. The Sprint Goal is the commitment, which you haven't mentioned once. Instead, you've described a situation where Developers just try to saw their way through tickets. What's the Sprint Goal they're aiming for? What significant risk or unknown are they trying to mitigate, and which makes their joint effort this Sprint coherent? What purpose does the Sprint serve, and gives them a reason to implement Scrum at all?

In Scrum the Developers commit to the Goal and not to the forecast of work, which only has to be accurate enough to satisfy them that their actual commitment is achievable. That forecast can be expected to change as more is learned about the work required to meet the Goal they've committed to.


07:18 pm October 19, 2022

It sounds like the Scrum Team is committing to scope. Teams shouldn't be committing to finishing all, or even some of their Sprint Backlog. The commitment made by a team is to achieve the Sprint Goal. Going into the Sprint, some of the Product Backlog Items selected for the Sprint are believed to be necessary to achieve the Sprint Goal, but by doing the work during the Sprint, the team may find that some of those selected Product Backlog Items aren't necessary, but may also find work that is needed that was previously unknown.

There is a technique that I've had good success with to help the team check the feasibility of their Sprint Goal. First, find the Product Backlog Items that the team believes are necessary to complete the Sprint Goal. Then, calculate if you can complete those items within about 70-75% of your Sprint's capacity. Whether you use velocity, hours, or cycle time and throughput, you can use the same rule of thumb. The result is often a highly achievable Sprint Goal with room to handle unexpected changes in capacity or unplanned work.

The advantage of consistently achieving your Sprint Goal is that your stakeholders can count, more often than not, on the team delivering the stated value Sprint-over-Sprint. However, something to keep in mind is the risk tolerance of the organization and stakeholders. If you are less risk tolerant, you can consider calculating against 65-70% of the Sprint's capacity. If you're more risk tolerant, then perhaps closer to 80%.

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.