Alternatives for Agile and Lean Roadmapping, Part 2: Rolling Wave Planning Inside One Quarter
An Agile expert explains the 'rolling wave' method of Agile planning, and how it can help you create a plan for your team's next month of work.
Join the DZone community and get the full member experience.Join For Free
In Part 1, I wrote about thinking in feature sets and how to quickly create a feature set of-with any luck-smaller features.
Because features change in value and because some feature sets need to deliver value on a more regular basis, the real roadmap looks more like the above graphic, "When the Agile Roadmap Changes."
Note that the top line feature set has more features in the first quarter, gets smaller through the 2nd and 3rd quarters, and is not so full in the 4th quarter. The second line is a feature set where we expect to see arrivals and deliver on a more regular basis. The third line has smaller feature sets and we need more delivery more often.
If we only had feature arrival and delivery on a regular cadence, we might be able to do one-quarter based planning and have it work. However, I have seen a ton of pressure for "Can you do more" and "We know we asked you to commit, but now we need you to change" at my clients.
When POs realize they might not need all the features in a feature set for an MVP or an MVE, they see the possibilities for more frequent planning.
Enter rolling wave planning. In rolling wave planning, you decide on the duration of the detailed plans, and as you finish one week, you plan the next week. Rolling waves always have the "wave" (the duration of the plan) as the details, and you refine the next week (or month) as you continue.
Example 1: Two Month Rolling Wave
Instead of detailed planning once a quarter, let's see what happens if you have a two-month rolling wave.
You might decide on a two-month rolling wave, where you have details for the first month, suppositions for the next month, and you'll plan the third month once you're done with the first. You refine the third month and maybe even create a supposed fourth month once you're in the third month. You always have a two-month wave where the first month is clear and the second month is supposition.
The product owners got together and created the first month worth of detail. They had a supposed second month (in pink) and the grayed third month showed their supposition but not commitment.
After the first iteration, they realized they needed to change the next iteration (the first part of the first month). They also realized they didn't quite know where they were going for the final iteration of the two months. That's why they had grayed out the final iteration worth of time.
They were pretty successful with that program. Then they had a new program and they realized two-month rolling waves were not going to work for them.
Example 2: One Month Rolling Wave
The organization had a program of six feature teams to work on a new product. They thought they knew their customers. But, this work would change how the customers used their product, from start to end. The POs were pretty sure they couldn't commit to anything as large as two months. They decided to use one-month rolling wave planning.
They had a one-month plan, but only details for the first two weeks and a supposition for the third week. Note that there are no stories specified for the fourth week and there is nothing else on the roadmap for past the fourth week. They used their big roadmap to talk about months, not quarters.
They were a little surprised by this. However, they used MVEs and MVPs to guide their work.
The more often you can plan in small chunks, the teams can deliver in small chunks. When the team delivers small value, people are less likely to pressure the team for more and/or to change what the team works on (I'll talk more about management lack of reality in a future post).
Not everyone can use a one-month rolling wave. I'll talk about flow-based roadmapping next.
Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.