“We do Scrum, and…” — Episode 7
Note: this article discusses User Story Mapping, Probabilistic Forecasting, MVP, epics and user stories. These are NOT mentioned in the Scrum Guide. They are complementary practices or terms that CAN be used by a Scrum Team.
In a recent article Paddy Corry showed how you can do delivery planning using User Story Mapping. I believe he presented an awesome way to create a rough delivery plan.
User Story Mapping as Delivery Planning
“We do Scrum, and…” — Episode 6medium.com
Paddy’s article triggered me to show an alternative way using Probabilistic Forecasting.
Probabilistic Forecasting summarizes what is known about future events. You will not work with single-valued forecasts but you assign a probability to a number of different outcomes.
Probabilistic Forecasting based on historical data is an alternative proposed by #NoEstimates. You don’t make assumptions, you use actual data. This makes it a powerful way of planning.
Story Map example
Below is an example Story Map, the starting point for the delivery planning forecast.
The initiative has 4 epics defined. As you can see the MVP has stories from all these epics. Release 2 to 4 also have stories from several epics. The information that we need for the delivery planning is the following:
The MVP has 7 stories at this point in time
Release 2 has 8 stories identified
Release 3 has 8 stories
Release 4 has 6 stories
Historical data
The historical information that I need is:
Team capacity: historical information on the number of items/stories that a team can finish per Sprint. I will use the following sample of the previous 10 Sprints: 2, 3, 4, 3, 2, 1, 1, 3, 2, 2
The user story split rate: what is the chance that stories will be split once created? For the MVP I will use a split rate of 25%; history showed that every 4th story was split. For the remaining releases the split rate can rise to 50% taking into account user feedback and other expected insights changing the backlog.
Throughput forecaster
I created the forecast using the Throughput forecaster from troy.magennis. It will take you 10 minutes at most to generate the forecast based on a Story Map and historical team data. I have written about the tool before:
My first experiences with probabilistic forecasting
Last week, for the first time ever, I communicated probabilistic forecasts. With this blog I try to describe how I came…medium.com
It is a brilliant tool that allows you to do forecasting based on estimates and historical data. It also allows you to plan on story points and on number of stories. I will not estimate my throughput and I also will not story-point-estimate. Hence I will be using the tool based on data only.
Planning the MVP
First thing to do is to provide the historical capacity of the team. As said this is 2, 3, 4, 3, 2, 1, 1, 3, 2 and 2 stories completed in the 10 previous Sprints.
Then I add the MVP data:
I assume the start date will be December 1st.
The low guess of the stories to be completed is 7. The high guess is 7 too.
Split rate is 25% (low guess 1.25, high guess 1.25).
Throughput time (Sprint Length) is 1 week.
I decided to use data (not estimates).
This is what it looks like:
And this is the probabilistic forecast of the MVP:
The results show that there’s a:
15% chance to deliver the MVP Dec 22nd 2018. This is very unlikely.
65% chance to deliver the MVP Dec 29th 2018. This is possible, but it is a stretch. It is unsafe to communicate this date only.
90% chance to deliver the MVP Jan 5th 2019. There’s a high chance that the MVP is ready by the date.
95% chance to deliver the MVP Jan 12th 2019.
almost 100% chance to deliver the MVP Jan 19th 2019. There’s no such thing as 100% certainty. The chance therefore is close to 100%.
Hence the delivery date of January 5th is highly certain (yes, everyone will be working during the holidays). You could choose to give this date as an estimate. However I prefer to be fully transparent by showing the complete graph. I found that stakeholders understand it with a little explanation.
Release 2, 3 and 4
For release 2 to 4 the split rate change to 1.25 (low) and 1.5 (high).
Now you can do similar exercises to create a planning for releases 2 (MVP+Release 2), 3 (MVP+Release 2+Release 3) and 4 (everything).
Below are the results for these:
The spread is larger than for the MVP, but still there’s only a 2 week difference between the ‘somewhat certain’ date and the ‘almost certain’ date.
There’s more than 2 months between the overly optimistic forecast and the 100% date.
Note that if you would calculate based on the average number of stories that a team can complete per Sprint (2.3) then you’d expect that the team would be finishing all items after 18 Sprints (also 18 weeks in this case). The throughput forecaster finds this only somewhat certain: the likelihood is 60%. If you wish to be more certain you should expect at least 20 Sprints. This is another reason to communicate the complete results.
Warning! — delivery planning and Scrum
Scrum is founded on empiricism:
“Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” — SG
You might argue that delivery plans violate this notion of empiricism. How can you possibly look 4 months into the future? I for one can’t. I did use historical data. Actual data from the team that will be working on the initiative. But…
will the team’s throughput remain unchanged for this new feature?
will the team’s split rate remain unchanged for this new feature?
will the team remain unchanged?
I can’t tell. Hence I need to take this uncertainty into account when I communicate the delivery plan. It is a snapshot of a certain moment with the information that was available at that time.
What is great about the throughput forecaster is that new information can directly be processed, whether it is a new insight on the number of stories to be delivered, new throughput information of the team or the user story split rate. As a result you can instantly process any change.
Delivery plans can give great insights provided that the stakeholders understand what they are and what they aren’t.
My examples — just like Paddy Corry’s — are a high level projection of possible delivery dates with the information that is at hand. They are NOT a promise.