Story Points explained - Part 6: Roadmap Planning
How can you effectively plan for more than a couple of sprints ahead using Story Points?
Are story points even accurate in long term planning?
Let's start by answering the second question. No, story point estimation is not accurate in long term planning. It is not accurate in short term planning either. Accuracy is not the point of estimating. Estimation gives us an idea. Sometimes estimations are more accurate, sometimes they are less accurate. That's why they are called estimations and not accurate predictions of future events.
The big mistake I see that organizations and leaders make is thinking that estimations are promises. Coming to the same understanding that estimations should not be treated as hard commitments, is a big mindset change. However, with that out of the way we can start improving the organizational ways of working.
The only value that estimations bring is in budgeting. Estimations answer a big business problem: How much does it cost?
In fact there are 3 business questions that we need to answer, as a business:
How long will it take to deliver feature X? (fixed scope, flexible date question)
Can this feature be done by this date? (fixed date, fixed scope question)
What can be delivered by this date? (fixed date, flexible scope question)
Answering these questions requires some good ol' fashion long term planning. The process for doing this is quite easy.
Make sure the high level ideas are split into smaller chunks of work (ideally less than an iteration)
Set up a Story Point Bucket system (each Bucket has a number of story Points assigned)
Go with the team through the stories and ask them to place each user story in a bucket
I've done this with multiple teams. It's quite easy to plan half a year worth of work using this technique.
This is an example of a Release Burndown chart in Jira. As you can see here we've had multiple rounds of estimations as more work was coming in. Especially in sprint 32 and 33. Based on the average velocity the team was able to deliver, we've discussed with the Business and we removed almost 2/3 of the scope.
Within a year, the team roadmap will one or more major releases. This team was delivering in production every sprint. However they had major milestones throughout the year. These milestones were marketed towards customers and stakeholders.
They were doing reviews to constantly adapt the scope of the backlog so that it better reflected the vision of the business.
In essence Roadmap Planning consists of two things:
What are the major business milestones the team needs to hit based on the current vision?
What do these milestones mean in terms of development effort?
Once you answer these two questions and have a clear understanding that we will Inspect and Adapt the scope based on what we discover, things become very easy.
