I started this series with the issues of trying to estimate/predict a specific backlog item quarters away, not even weeks away. (Even weeks away is iffy because the entropy is the default state for the world.)
In Part 1, I suggested that the team can use cycle time, but even with cycle time, we need to beware of predicting anything that far off. I used the example of my lunch: I know I will eat lunch. And even with my limited options, I do not know precisely what I will eat on a given day.
That's analogous to a team's problem with that kind of prediction: With cycle time, the team can be pretty sure they will deliver something, even if they don't know what they will deliver.
In Part 2, I suggested the product leader/team/some combination, have a conversation to understand the context for the request. Because while I don't see how anyone can answer this question, there's often a reason behind the request.
In reality, the question of “How do you want to use this information” is my single best tip. However, you might want to know about all the other ideas. So here's the summary, starting with my principles behind estimation.
Prediction/Estimation Principles
First, a couple of notes about trying to decide about work very far in advance:
- Long backlogs are Gantt charts in disguise. See Large Features and Long Deadlines Mean You Have a Gantt Chart, Not a Roadmap. The longer the backlog, the less agile you can be, because no one's incorporating learning into the work. In my experience, users don't need (and don't want) most of the features teams spend forever trying to finish.
- Worse, long backlogs tend to mean that teams become feature factories, instead of focusing on the overarching goal for this product. (See Do You Have Feature-Itis?)
Now, some principles about prediction or estimation:
- It's not possible to perfectly predict anything. Worse, it's not even reasonable to consider that request if the work is farther out than a few weeks. (I say 4 weeks is the maximum, and that's pushing any prediction.) That's because the people on the team will change (even for time off), or the backlog will change.
- If your managers want you to predict any date, make sure you offer at least three dates: Possible, Likely, and Pessimistic.
- Or, show people a Monte Carlo simulation based on cycle time. Especially, show them the difference between the 50%, 80%, or 90% confidence levels.
Be careful about how you assess feature sets:
- The more you decompose requirements, the more buffers people will build in. All the work will look as if it will take forever. That changes how organizational leaders feel about the project.
- Instead, use the brainstorm ideas in Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets. (That link goes directly to the heading “Brainstorm Each Feature Set”.)
Then, I offered you some practical tips.
Practical Tips for Any Team Struggling with Prediction/Estimation
I really hate predicting when I will finish any of my work, and I have no other interdependencies. That's because I cannot predict when possible clients will call or when I make a mistake writing and need to think to fix it. That's analogous to your team having production support or other questions for the team.
Teams have these options:
- Release small pieces of value several times a week. So everyone can see visible progress.
- Create a weekly cadence of public demos. Again, so everyone can see visible progress. That builds trust across the organization.
- Every team, including managers, should measure their cycle time. You can use a back-of-the-napkin approach by counting the number of completed stories per unit time. That's probably close enough if someone wants you to predict the unpredictable.
For decades, I've advocated that people work in inch-pebbles, one- or two-day tasks that are either done or not done. (See Using Inch-Pebbles to Track Project State.) If you use an agile approach, I recommend teams stop estimating. Instead, I suggest the team right-size the work so the team can complete the work in about a day or two.
I hope these tips work for you. But at the risk of repeating myself, to reply, ask what the requestor will use this information for.
What Value Will This Information Provide?
And always, ask about the plan for this information. If you know why the person wants this data, you can offer something more useful. Part 2 was all about seeing the requestor's context so you can provide some useful alternatives to estimation. Remember, information degrades over time. (See Product Planning, Information Persistence, & Product Lifetime for more information.)
The requestor wants to be able to depend on your information—that's why they want a prediction. And the team wants to work forward, not to be “held accountable” for a long-ago prediction.
Ask how the person will use this information before you do anything else.
I hope you consider reading Predicting the Unpredictable and seeing where you can make your estimation more effective. But to answer the original question: No, there is no way to explain to anyone what you will deliver several quarters out. You might be able to predict the next month with some accuracy, but not anything beyond that.