“When will it be done?”
It’s one of the most asked questions in all of product development.
For many product makers, especially agile ones, this question invites further questions, like “why do we even need a date?”, or, does done include:
- speculative features?
- unnecessary bells and whistles?
- more than our customers actually need?
While those are important questions that deserve discussion, in this blog, I’m focused on those times when a date is needed, and when the people asking for a date have good reasons for requesting one.
So how can we give them an accurate answer?
Probabilistic forecasting can help.
If you combine daily throughput (the actual time it takes to complete work items) with thousands of Monte Carlo simulations, you get probabilistic forecasting, a way to predict date ranges for finished work.
My colleagues and I at Industrial Logic have found that this approach yields accurate dates, given good inputs (more on that later), and invites conversations about how to reckon with reality when people don’t like the forecasts.
A Real World Example
Here’s a look at a probabilistic forecast, based on the work of an 18-person Industrial Logic team, which is currently helping a client re-write a legacy product:
The chart, created by an Actionable Agile plug-in to a client’s Jira tool, provides a good deal of analysis and detail about when we can expect a bunch of work to be completed.
It uses the team’s daily throughput numbers, along with over 10,000 Monte Carlo simulations, to arrive at likely date ranges for delivery.
The calendar (at the bottom of the graphic) indicates that anything in dark green means that there is a 95% chance of delivery (according to the legend, in the bottom right corner).
We’ve found that such data helps us have useful conversations with clients about expectations, and when necessary, opens a door to exploring potential ways to deliver sooner.
My colleagues and I have been using probabilistic forecasting for many years now, starting with a spreadsheet created by Troy Magennis, to our latest use of Actionable Agile software.
The accuracy of the forecasts has meant that when delivery dates aren’t soon enough for a client, no one questions the accuracy of the forecasts. Instead, we get creative in ways to deliver sooner.
For example, probabilistic forecasting recently helped us learn that forecasted dates for completing a large-scale, legacy code rewrite would not meet business needs.
This led us to expand our team globally, remove delays in client collaborations, and tighten our process.
A month later, the probabilistic forecasting looked far better, and a little while later, it predicted earlier delivery of important milestone releases.
It’s worth noting that on date-critical initiatives, we look at and report on probabilistic forecasting frequently, so we can have an accurate idea of how we’re doing and what, if anything, we need to adjust.
One key to getting accurate estimates is having good input data.
In general, if the size of the work items computed for throughput is relatively consistent, you get better probabilistic forecasts.
This naturally leads our teams to work in small batches (a Lean term), breaking work down into small, thin, “vertical slice” user stories.
Doing such work requires a good understanding of evolutionary design, a practice that I continue to find lies at the heart of agility in product development.
Where Can You Learn More
Some pioneers and leaders of this practice include:
- Troy Magennis:
- Dan Vacanti (who is also a decent tennis player)