Agile roadmapping

“The best way to predict the future is to invent it.” – Alan Kay

Every so often, I hear someone suggest that you can’t really build a roadmap when you’re working in Agile, because you’re only planning one iteration at a time.

That, my friends, is nonsense. In this article I’ll describe a lightweight planning process for building a roadmap for strategic development items, that you can share with internal stakeholders and even external customers, without locking yourself into a detailed plan that you’ll come to regret later.

Depending on your company, the lifecycle of your product and its complexity, you can build this roadmap out to look two or three years ahead without embarrassment.

Why build a roadmap anyway?

A medium- or long-term roadmap is really useful to steer the direction of travel for your product, and to set expectations within (and potentially without) your company.

It helps you with the balance between strategic developments and day-to-day requests. Without a roadmap, it’s all too easy to concentrate on low-hanging fruit, and before you know it months have past and you haven’t tackled the big, strategic stuff. Building a roadmap gives you a framework to help you keep on track.

And for your own benefit, a roadmap can reduce the frequency of people from other parts of the business bothering you about when you’re going to get around to doing A, B or C.

Focus areas for your product stories

In its idealized form, the Sprint Planning process takes one iteration’s worth of user stories from the top of the prioritized Product Backlog, and moves them to the Sprint Backlog.

In practice, we rarely stick strictly to our priority order. For example, we might group related user stories together to save on context switching, even if that’s not absolutely in strict obeisance to whatever scheme we use to prioritize those stories.

 

Each strategic project is a set of related user stories

When we start thinking about the big, strategic development items that we want to tackle in the future, we know that they will be made up of a number of related user stories – even if we haven’t yet broken out exactly what those user stories are.

We can build a roadmap simply by saying that for each strategic development initiative, we will set aside a period of time in which we’re going to prioritise enough user stories in that area to build (at least) an MVP. (This is essentially the time-boxing approach that Martin alludes to in Prioritisation 101.)

Sizing your strategic projects

Your next task is to find these strategic initiatives and get a rough idea of how much effort is needed to complete an “MVP” for each. (Just in case you’ve been on Mars for the last couple of years, that’s ‘Minimal Viable Product’, or the bare minimum set of features you can develop that could be considered to fulfill the functionality. No bells, no whistles.)

You don’t need to break the project into detailed user stories, but you might think it wise to identify roughly what the MVP is (and that may mean agreeing with your sales team or exec leadership what they are prepared to accept as a bare minimum). This might involve a few sketches, but don’t go crazy – the chances are quite high that the requirements will change before you get to the project anyway.

Next you need a rough idea of how much effort is involved – at a granular level, perhaps simply the number of iterations. One approach is to identify a previous project of similar complexity, and see how many iterations that took. You might like to sanity check this rough sizing with the development team.

For really big strategic areas, you’ll want to break them into separate phases, each of which has its own logical ‘MVP’.

Prioritize your strategic projects and plug them in to a quarterly plan

Here’s a rule of thumb: if your rough sizing says that the MVP for a project will take less than a couple of months, assign it a full quarter in your roadmap. If it’s going to two months or more to build the MVP, give the project two quarters (and think carefully about whether you couldn’t break it down into smaller projects).

By assigning more time than the MVP takes, you’re building time into your roadmap that can be used for a combination of

• iterating the MVP, test-and-learn stylee
• adding some of those bells and whistles
• urgent items that will inevitably come up
• dealing with low-hanging fruit from your backlog.

Feel free to adjust the timescales to what suits you, but the important thing is not to get bogged down in the detail – my experience is that one big project per team per quarter is about right for roadmapping. The more detailed your plan, the more likely it is to be wrong. If you find yourself planning sprint-by-sprint more than a couple of months ahead, in my opinion your plan is definitely wrong already.

Other factors

There are tons of external factors that might affect your roadmap.  Many of them are totally unpredictable – and there’s no point burning cycles worrying about them too much.

On the other hand, you should plan for the predictable things.  Supposing that your company is planning to expand, and you expect to have extra development resource in six months’ time, then factor in that resource into your roadmap – in the example roadmap above, we show an extra development team coming on board at the start of 2013 so we have capacity to handle two strategic developments in parallel.  (If the expansion doesn’t happen as planned, you’ll have to rewrite your roadmap accordingly.)

If there’s a single binary outcome that could massively affect your future (like, “if MegaCorp really do license our product like they’ve hinted”) then why not build two entirely separate roadmaps to cover both scenarios?

Sharing your roadmap

Get buy-in from your team as soon as you can, and make sure the plan feels plausible to them.  I’ve generally found that development teams like the idea of focusing on something meaty for a decent chunk of time, so they can really make a difference in that area.

When you share your roadmap with other stakeholders, you need to set the right levels of expectation.  If there are items you don’t want your sales team to commit to customers, then make sure that’s absolutely clear (perhaps this is the one occasion when a flashing font is acceptable?)   Conversely, if there are items in your roadmap to which your company is contractually bound, it behooves you to continually check your progress against the roadmap to make sure you’re going to meet your commitments.

Prioritising user stories to match the roadmap

As the Product Owner, it’s up to you what criteria you use to prioritise user stories for each sprint. As you approach each new quarter, weight the priorities so that the stories for the strategic project you planned to work on get to the top of the list, with the MVP stories at the very top. I like to map out roughly what I think we’ll be able to do in each sprint, to make sure it seems plausible that we’ll deliver at least the MVP as expected.

No doubt, additional urgent things will come up to trump some of the strategic stories, but you have built capacity into your roadmap to allow for that. However, if  you find you’re not getting to the strategic items within the first iteration or two of the quarter, alarms bells should definitely start going off. Either your resourcing is not what you planned for, or something has changed that means your plan is not likely to reflect reality.

Is this really Agile?

This approach is 100% consistent with Agile. All you’re doing is thinking ahead about the shape of your product backlog.

For each of your strategic projects, you’ll get at least an MVP – and with a following wind you’ll also have capacity for further iterations and improvements in that product area before you move on to the next focus area. How much more Agile could you get?