From time to time development teams will not finish all the work they’ve forecasted for a Sprint. Typically, this occurs because a user story or two may have been more difficult than planned, leaving other work undone. When it continues to happen Sprint after Sprint, we must begin to look at patterns that may lead us to a root cause. While there could be many root causes, I will address only a simple, but common one for starters: Development teams over-committing in their Sprint forecasts.
Consider this: A Product Owner must be able to communicate to stakeholders the status of their requests (user stories). The communication with stakeholders takes place often, including right after Sprint Planning, to let stakeholders know that their requests (user stories) are part of the current Sprint. It’s important for Product Owners to have some predictability as to the development team’s ability to deliver on the Sprint forecast so they can build confidence with their stakeholders. Over time Product Owners and stakeholders may begin to lose confidence in the development team’s ability to deliver against its forecast if the pattern continues for long periods, resulting on low customer satisfaction.
The development team’s average velocity is the average number of story points the development team can get “done” in one Sprint. New teams have to “wing-it” to determine their average velocity until they develop a few sprints of empirical data allowing them to forecast their velocity. Over time a team’s average velocity becomes more refined and more predictable. Average velocity is the primary tool the development team uses when forecasting their work for a Sprint during Sprint Planning. For example: if the development team’s average velocity is 50, then the development team should not forecast more than 50 story points of work for the Sprint during Sprint Planning. New teams tend to be overambitious and over-commit on their forecast during Sprint Planning, well beyond their average velocity, because they haven’t built trust in the empirical data (average velocity). The result is that the team may commit to 60 or more story points worth of work, but still only finish 50, with 10 or more story points carrying over to the next Sprint. What do we do when this happens? Unfortunately, developments teams will tend to underestimate the remaining effort for the 10 story points and likely pull in another 60 or more during Sprint Planning, even though their known velocity is 50, based on the empirical data. The cycle continues until the team decides to put a stop to it or the Product Owner and stakeholders begin to get frustrated and confidence begins to drop.
How do we fix this? There’s a saying in the lean agile community; “stop starting, and start finishing”. Sounds simple, but that’s exactly what we have to do. In the scenario above, we still have 10 story points carrying over to the next Sprint. Instead of over-committing with another 60 or more story points or even adding 50 story points which is our velocity, try only adding 40 story points, for a total of 50 (40 new, plus 10 carried over). Yes, some of the work may have begun on the 10 story points that carried over, but that’s ok. Let’s focus on finishing old work before starting new work. Worse case, if the team is able to deliver the 50 before the Sprint ends and runs out of work, the Product Owner can ask the team to pull in an additional story from the backlog.
Higher job satisfaction will emerge when a team delivers everything it forecasted. Bottom line, forecast with care, and you, your Product Owner and your Stakeholders will be much happier.