Create Rolling-Wave Roadmaps

Agile approaches invite change. The more often a team completes one small feature, the more often the product owner and team can change what the team delivers next. I like to show these possibilities with rolling-wave roadmaps.

There are at least two reasons to use rolling-wave planning:

• We might get far enough into a feature set and realize we don’t need to do any more, either at all or for this project.

• Agile approaches invite change. With rolling-wave roadmaps, we can show people how things might change.

This figure that follows shows a possible one-quarter rolling-wave roadmap.

This roadmap shows an internal cross-organizational release every month. In addition, the team releases formally to itself and the product owner on a cadence of every two weeks. That’s why you see the “MVP for release” at the end of the iteration/cadence.

I’ve only specified a few stories for each two-week time. Your team might define fewer stories if it’s in flow, or more stories with timeboxes.

I’ve color-coded the two-week chunks of work. The left-most chunk is clear, either what the team has completed or what is currently in the backlog. The next three are somewhat gray and the last two are grayed out. The next three are our plan, and the grayed boxes are what we think the plan is. We can see the uncertainty by seeing how much is grayed. The six shaded boxes on the bottom are the actual stories in each feature set.

Many teams discover they need to accommodate more change and learning than a three-month rolling wave provides. Consider a maximum of a two-month rolling wave, as shown in the next figure.

When product owners and teams use roadmaps like these, they have the option of changing the next bits of value. Starting with the two-month rolling wave, this product owner changed the value, as shown in the next roadmap.

The product owner decided there was more value in starting Text Transfer and Diagnostics rather than the original plan.