post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Building for change: When transformation and product management meet

Product Development

What are product features? Definition, examples, and 5 types

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Lessons from my first year as a Prod Ops Manager

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Liz Rice

<blockquote>“The best way to predict the future is to invent it.” – Alan Kay</blockquote>
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.
<figure id="attachment_2132" aria-describedby="caption-attachment-2132" style="width: 362px" class="wp-caption aligncenter"><a href="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.18.56.png"><img loading="lazy" decoding="async" class="wp-image-2132 " src="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.18.56.png" alt="Product Backlog" width="362" height="332" srcset="https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.18.56.png 452w, https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.18.56-300x275.png 300w" sizes="(max-width: 362px) 100vw, 362px" /></a><figcaption id="caption-attachment-2132" class="wp-caption-text">User stories prioritised in the Product Backlog</figcaption></figure>
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.
<figure id="attachment_2133" aria-describedby="caption-attachment-2133" style="width: 419px" class="wp-caption aligncenter"><a href="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.19.39.png"><img loading="lazy" decoding="async" class="wp-image-2133 " src="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.19.39.png" alt="Grouped stories in the product backlog" width="419" height="362" srcset="https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.19.39.png 524w, https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.19.39-300x259.png 300w" sizes="(max-width: 419px) 100vw, 419px" /></a><figcaption id="caption-attachment-2133" class="wp-caption-text">Grouping related stories means we might not tackle them in strict priority order</figcaption></figure>
&nbsp;
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 &#8211; 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 <a title="Product Prioritisation 101" href="http://mindtheproduct.com/product-prioritisation-101/">Prioritisation 101</a>.)
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&#8217;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).
<figure id="attachment_2134" aria-describedby="caption-attachment-2134" style="width: 593px" class="wp-caption aligncenter"><a href="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.20.21.png"><img loading="lazy" decoding="async" class="size-full wp-image-2134 " src="http://mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.20.21.png" alt="Example Roadmap" width="593" height="216" srcset="https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.20.21.png 593w, https://www.mindtheproduct.com/wp-content/uploads/2012/08/Screen-Shot-2012-08-03-at-15.20.21-300x109.png 300w" sizes="(max-width: 593px) 100vw, 593px" /></a><figcaption id="caption-attachment-2134" class="wp-caption-text">Example Roadmap. Each coloured box is a project.</figcaption></figure>
By assigning more time than the MVP takes, you’re building time into your roadmap that can be used for a combination of
<ul>
<li>iterating the MVP, test-and-learn stylee</li>
<li>adding some of those bells and whistles</li>
<li>urgent items that will inevitably come up</li>
<li>dealing with low-hanging fruit from your backlog.</li>
</ul>
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&#8217;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&#8217;ll be able to do in each sprint, to make sure it seems plausible that we&#8217;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?

Agile roadmapping

Liz Rice

Read more

Comments