Charting a path to the future: roadmaps and story maps

14 June

One of the common misconceptions about Agile development is that products are built without any planning or thought to overall architecture and product design.  That we “write code like free form poetry” (to quote my friend James King).  Of course the reality should be far from this state.  To effectively solve a business problem or take advantage of an opportunity we need to have a vision for what the future will be like and a map to help us get there.

In product development this map typically has two levels of granularity – the broad product Roadmap that identifies key features and dependencies out for about the next 12 months or so and the Story Map which identifies the key elements of the product which could be delivered over the next 3 months or so.  This two-level planning approach allows us to communicate with the wide range of stakeholders about when they can expect to see what features or capabilities, and it gives us the ability to flex in response to changing conditions in the marketplace or evolving needs in the organisation.

 

The Roadmap

The term roadmap is used very deliberately – we need to know where we are headed and where we are now, and can then use the map to plan the best route between the two points, however as we progress on the path we can adapt our journey based on reading the current situation – if one road is blocked because of a traffic jam we can change direction in order to get around the blockage, sometimes we will deliberately chose a path that is longer but it is more scenic, or it avoids a dangerous part of town.  Just so with our product roadmap – we start out with an idea of what the features or capabilities will be and we are able to adjust based on the feedback we receive from our incremental delivery approach.

To prepare a product roadmap we need to consider more than just the features or capabilities of our product – we need to consider other areas of the organisation and how their needs will impact on the product development group.  We also need to take into account what is happening in the marketplace around us – things that we may want to respond to or avoid in our product delivery.

Typically a product roadmap charts four elements which will help us decide what to build when:

  • Marketing needs.   What would our marketing group want to promote when, are there specific campaigns which will influence the delivery of the product features?
  • Features/benefits of the product.  The features or capabilities we want to build in into the product over the timespan, in the order we believe will be most sensible in terms of achieving valuable outcomes rapidly.
  • Technology changes that need to be supported.  For example underlying operating system changes, new platforms and other technical considerations.  This will come from the organisations technical strategic planning.
  • Market events.  Things which we have no control over which we want to take advantage of (have a product launch with specific capabilities in time to take advantage of the Christmas purchasing period) or avoid (lots of people taking their summer vacation at the same time so velocity will reduce)

It’s generally worth producing a visual roadmap which identifies these four elements, and making it available for all the stakeholders to explore:

We know that this roadmap will change and it should be regularly re-evaluated as part of an adaptive portfolio management approach.  The further away a feature is on the map the less clarity we expect about it as there will be a steady evolution of customer and market needs.  The closer something is the clearer our understanding needs to be.

 

 

Q1

Q2

Q3

Q4

Marketing Needs

 

 

 

 

Market Events

 

 

 

 

Technology Changes Needed

 

 

 

 

Features/Capabilities to be Implemented 

         

         

         

         

 

Photo of a product roadmap 

An example of a Product Roadmap for a product (Livestock Improvement Corporation)

To make the Product Roadmap real and implementable by a development team we take one quarter at a time and turn it into a User Story Map.

 

A Closer Plan – the User Story Map

In order to identify which pieces of the product to build next we need to build a backlog of discrete elements of functionality which constitute the product deliverables.  To populate this backlog the most common technique in Agile product development is the User Story.  A User Story is a small, discrete piece of business value expressed in terms of who it is for, what the feature or capability is and why it matters:  As a <role> I need <capability> so that <benefit can be realised>.

However a one-dimensional list of hundreds of user stories quickly becomes unmanageable and impossible to envisage the overall product needs.  To overcome this we suggest using the User Story Map, a technique described by Jeff Patton in his book User Story Mapping: Discover the Whole Story, Build the Right Product (https://www.amazon.com/User-Story-Mapping-Discover-Product-ebook/dp/B00NF07FHS)

We strongly recommend building a User Story Map for one quarter of the Product Roadmap at a time, and only do so when you are getting ready to deliver the features and capabilities planned for the quarter. 

A User Story Map is a two-dimensional grid in which the top two rows identify the User Activities and User Tasks that users will want to do with the product and the remainder of the grid shows the discrete pieces of business value which will be delivered (the individual user stories).  The User Activities logically group topics that are related (eg Identity Management could be a User Activity), User Tasks show the separate elementary business processes that will be undertaken within an Activity (eg Set up a new user, change a password, disable an account could be three discrete User Tasks under the User Activity Identity Management). 

The bulk of the User Story Map is made up of the separate User Stories that contribute to the Activities and Tasks, sequenced by their ranked business value.  The horizontal rows on the map show the logical handoffs between Tasks and Activities and their order from top to bottom of the map shows priority for development.

 

 Photo of a user story map

An example User Story Map showing a set of User Tasks and their related User Stories

 

Post by Shane Hastie

Thank you!

Your details have been submitted and we will be in touch.

CHAT
CALL