Why should the sprint forecast be accurate?
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?
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.
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%.