Forecasting past 1 Sprint
Hi all,
I’m aware there are various methods as to how to do this, but I’m keen to understand how other Agile practitioners forecast the completion of backlog items in the product backlog when these items are not well understood and refined enough to be estimated.
For example, there are 30 backlog items that once complete would achieve x business benefit and we want to forecast the completion of these. We know this forecast will be based on assumptions and will change based on learnings, emerging work, opportunities etc.
I’m keen to understand how other Agile practitioners forecast the completion of backlog items in the product backlog when these items are not well understood and refined enough to be estimated.
They aren't refined enough to be estimated. They're refined enough to be Ready. Eventually, through refinement, work will become small enough and sufficiently well understood to be Done in a Sprint.
Estimated work that is revealed to be too large or ill-defined to be Ready is nevertheless still an estimate.
Estimation, if you are using that practice, is part of refinement. There are many possible attributes for a Product Backlog Item to have, one of which could be an estimate. If your team is estimating, then breaking down and defining the Product Backlog Items will allow the team to estimate them. The estimate could lead to more refinement if the team feels the work is still too large, so just because a Product Backlog Item is estimated doesn't mean that refinement on it ends.
Once you have well-refined work, there are several techniques that you can use. It depends on what methods you are using on the team.
You could think about using velocity, but velocity is highly dependent on a number of factors. Relative estimates tend to shift as the team learns more about the product and domain and the team recalibrates, so it's not a good measure to look forward or backwards for a long time.
If you are estimating in ideal hours and you know how ideal hours are related to real hours for your team, you can project how many real hours it would likely take to complete the work, converting this into Sprints.
If you're using flow metrics, you can use throughput to figure out how long it'll take work to flow through the process. You will need sufficient actual data on throughput and cycle time to compute this, though, so having insufficient historical data will make this a very rough estimate.
Regardless of the method, the longer you look forward, the more likely it is to be wrong. More valuable work may be introduced, disrupting the ordering of the Product Backlog. Changes to the team's way of working may influence how much work they can complete per unit of time. Learning more may lead the team to introduce more work items to the backlog.
I suggest you read these two book from Daniel S. Vacanti.
Actionable Agile metrics for Predictability
When will it be done?
These two books will provide you insights and knowledge of how to help your team become predictable and then use that predictability to forecast. That same site provides a tool to make the work from the books easier.