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 to this point and…
Last week, for the first time ever, I communicated probabilistic forecasts. With this blog I try to describe how I came to this point and what my initial experiences are. I know that probabilistic forecasting has been there for ages, but still I am the first person in the company (as far as I know) doing this. It may sound unbelievable for some, but the organization sees this as an experiment.
I was asked to give my projections for work on two epics. One of the epics is already split into well refined user stories. The other epic was only roughly split at that point in time.
Epic 1 consists of 11 user stories. The story point estimates are 13, 8, 8, 8, 5, 5, 5, 5, 3, 3, 3. The first two stories need to be developed first and the remaining stories can be developed in any order.
Epic 2 is expected to have around 6 stories, but we still need to start refining them. We estimated the epic to be 40 story points. Our previous experiences tell us that on average 6 stories easily split into 9 during refinement. About every 2nd story that we refine needs to be split in two.
The way I used to estimate
When I estimated previously I used to calculate the number of story points and then I would determine, based on the average velocity of 30, how many sprints it would take to deliver the whole epic. Of course I would take into account the size of the individual stories to not put too much in a sprint.
I calculated that we would be needing 2.5 sprints of two weeks to deliver the stories. This would mean that we would be able to finish epic 1 by December 27th.
Epic 2 would take 1.5 sprints if we take into account the 40 story points. We would be able to start halfway the sprint ending on December 27th. Therefore we should be able to deliver epic 2 by January 10th. For epic 2 we would inform the stakeholders that we could be 50% off, which means that there’d be a good chance that we would only deliver the full epic by January 24th.
Probabilistic Forecasting
An Agile coach at my work knew about my emerging interest in the topic of estimating and forecasting. He pointed me towards Troy Magennis’s forecasting spreadsheet: http://focusedobjective.com/single-feature-forecast-spreadsheet/. It’s a very straightforward, easy-to-use tool.
I knew my team’s throughput history, so I entered the data of the past 9 sprints first. Important to know is that the throughput is on average 4.5 stories per sprint. Then I went to the ‘Forecast’ tab, where I could see that the sample data quality was great:
I entered the starting date, low guess and high guess of number of stories (11), the probability that a story would be split (between 0% and 10%) and finally the duration of a sprint.
The spreadsheet hypothetically completes the work 500 times and the results are immediately shown.
For epic 1, these where the results coming from the spreadsheet.
What I like about it is that it says it’s 80% certain that December 27th all stories will be done. The probability of this to happen is however a bit on the low side. It would be a safer bet to communicate January 10th.
It got even more interesting with epic 2. When I included these 6 stories I also raised the probability that the stories could be split (20% to 25% — remember that 11 stories were already refined quite thoroughly, so the total of 17 stories is less than 50% to be split in 2).
For epic 1 and epic 2 together, these are the results coming from the spreadsheet:
So, while with my former estimating technique I estimated that January 10th should be achievable, but that it’s better to aim for January 24th the forecast informs me that January 24th also only has a probability of 60%. It’s a far safer bet to communicate February 7th.
Experiences so far
I like the fact that the forecast is solely founded on throughput, regardless of the size of the story. This enables you to estimate and plan at an earlier stage. I also very much like how easy and intuitive the tool is. On top of that I love the fact how several possible dates are presented with a probability of it happening. Also, it treats the team’s capacity as a given and not as something that should be challenged. At least that how it feels to me.
The stakeholders that I shared my forecast with were -except for one person- all very enthusiastic. It provided them with far more information than what they received before. Before they only got a date. Now they get possible dates with a good story. One person found that it all took too long and asked me for a better planning. I assume this person only likes dates when they are fitting her planning (which is asap no matter what).
Another nice thing is that I can change the input fields any time when I have new information impacting the calculations and I will get an instant update on the forecast.
I intend to continue giving updates on my experiences and I am very interested in your feedback on the practices described.
If you liked the article I’d appreciate it if you would 👏🏻
Originally published at ageling.wordpress.com on November 20, 2017.