The Difference Between a Forecast and a Commitment
For anyone who has been involved with software development practices for a significant amount of time, it will come as no surprise that teams often face unrealistic expectations when it comes to delivery of completed software.
This article on the Tyner Blain website sums up the nature of the challenge nicely, with these words:
In the old world, you would commit to delivering a couple pyramids. After spending double your budget, with double the project duration, you would have delivered one pyramid. When you deliver it, you find out that sphinxes are all the rage. Oops.
Your team changed to agile, so that you could deliver the sphinx. But your Pharaoh still wants a commitment to deliver a couple pyramids (the smart ones will be expecting to get just one). You can stay true to agile, and still mollify your boss’ need to have a commitment, if you take advantage of the first-principles of why agile estimation works.
When did the term Sprint Commitment fall out of favor?
There was a time, specifically going back to the original version of the Scrum Guide (published in 2010), where there was a notion of a“Sprint Commitment,” which was understood by a great many people to mean that a team could forecast, with a high degree of certainty, exactly how many user stories they were going to finish during a Sprint.
To the casual observer, such a concept might sound reasonable. Unfortunately, what happened all too frequently was that the Sprint Commitment was used as a blunt instrument with which to bludgeon any Team, and/or its Product Owner or Scrum Master, that failed to meet its Sprint Commitment. Worse still, even if the Team had to move mountains to finish the work they did finish, if they fell even one user story short of the commitment, they might have to go before the organizational equivalent of a firing squad.
There is simply no good long-term outcome from such a scenario.
We are now entering the cone of uncertainty
One of the fundamental challenges when it comes to predicting how long it will take to finish anything, and in particular, software, is the cone of uncertainty.
The problem is this — Teams are typically asked to forecast how long it will take them to finish something when they know the least about it — at the very beginning. Compounding the problem is the fact that the further into the future a Team is trying to forecast, the less accurate a forecast will be, and on the cone of uncertainty, such a decline in certainty is shown as a “widening of the confidence bands” for the forecast.
If not a commitment, how about a prediction or a forecast?
Now we get to where the rubber meets the road. Based on the uncertain nature of software estimation, how is it possible to predict when some set of software features will be done?
The content from the “Commitment” section of the Tyner Blaine article mentioned above is as good as anything I have seen written on this topic:
The backlog represents the work the team is going to do — in the order in which the team is going to do it. Over time, as we get smarter, we will add and remove items from the backlog — because we discover new capabilities that are important, and because we learn that some things aren’t worth doing. We will even re-order the backlog as we recognize shifting priorities in the markets (or in our changing strategy).
As this happens, it turns out that the items at the top of the list are least likely to get displaced, and therefore most likely to still be part of the product by the time we get to the release.
Instead of thinking about uncertainty in terms of how long it takes, think about uncertainty in terms of how much we complete in a fixed amount of time. In agile, generally, we apply a timebox approach to determining what gets built.
Now, uncertainty, instead of manifesting as “when do we finish?” becomes “what will we finish?”
Using risk multipliers to adjust predictions
In a post on his blog, Jim Shore talks about the use of a couple of techniques to help account for how much uncertainty and risk there is for any given body of work, and shows how to apply some simple math to adjust predictions accordingly.
Take a look at the examples that Shore provides in the blog post, which cover the usage of risk multipliers and also how to create and update a “risk-adjusted burn-up chart.”
Shore closes the blog post as follows:
One of the cool things about this technique is that it automatically accounts for Steve McConnell’s famous cone of uncertainty. Look at the risk bars over time and you’ll see how they become smaller and more certain as time progresses, just as McConnell predicts.
Make a point of also reading the blog post where Shore talks about what not to do: Estimate Inflation: A Cautionary Tale.
Probabilistic forecasting
For an additional perspective on prediction in an Agile context, see Willem-Jan Ageling’s post called User Story mapping and probabilistic forecasting, where he outlines an approach that utilizes one of Troy Magennis’s more popular tools, the Throughput Forecaster, in conjunction with Story Mapping.
Focusing on a short time horizon — Sprint Goal
As I mentioned at the beginning of this blog Post, the language about commitments in the Scrum Guide has changed over time (The Scrum Guide was just updated in November, 2020, and now there are three “commitments:” 1. The Product Goal (associated with the Product Backlog); 2. The Sprint Goal (associated with the Sprint Backlog); and 3. The Definition of Done (associated with the Increment).
It has been a truism for successful teams that the Sprint Goal can help focus the conversation about what the team hopes to achieve during the Sprint. In other words, based on the Team’s forecast of how much work they think they can get done during the Sprint (a forecast which seldom, if ever, can be made with absolutely certainty), they work with the Product Owner to craft one or more Sprint Goals that are reflective of what completion of that body of work would look like in terms of outcome(s), and, importantly, constitute a body of work that team members truly believe is attainable.
