Governing a software product’s scope using User Story Maps

How do you convey and manage the scope of your software product, and what tools do you use to monitor and govern your progress towards its delivery deadline ?

I am a strong advocate of using User Story Maps to answers these questions and convey the scope of the product being created.

I find that a product’s scope is often locked in backlogs and it is hard to quickly determine how the user stories combine to fulfil the product’s user journey. It often requires significant time with the sprint team to draw this out and visualise the high-level view of the release plan and roadmap for a product.

Then when you add the need to understand how a product’s scope has evolved over time, and in particular visualise this, it becomes a complex activity to piece this together.

For example, as a Product Owner, if I asked to visualise how my user’s journey has evolved over time, or how my prioritisation decisions have moved stories between sprints or even moved them to be out of scope then could your sprint team quickly show this ?

A User Story Map (or Feature Map) addresses these issues by providing a single view of the user journey, and the epics/user stories required to deliver it.

There has been other blogs and articles written about User Story Maps (https://www.productplan.com/glossary/story-mapping) and Feature Maps (examples include https://johnfergusonsmart.com/feature-mapping-a-lightweight-requirements-discovery-practice-for-agile-teams and https://www.ivarjacobson.com/publications/blog/feature-mapping-scaled-agile-framework). These provide good walkthroughs of the activities undertaking to create User Story and Feature Maps.

If you’ve not created or used these maps before then let me provide you an example and quickly explain its virtues.

The following is an example from a project that builds a product for scheduling staff to a 24-hour rota. The stages of the user journey are laid out at the top of each column and each of the user stories are mapped to the stage of the journey that they fulfil.

From my User Story Map I can see the number of stories needed to fulfil each stage of the user journey. I can see which stories have been prioritised for release 1, those for release 2 and which are currently out of scope.

Our Story Map canvas has been enhanced with a few extra details from what you would traditionally find. These have been added from experience over the years; each to aid and assist the Product Owner and spirit team to visualise and govern the product’s scope.

Some examples and their benefits:

· Our map doesn’t only show the user journey, in the example above we have added other key elements needed to deliver the production-ready product, for example non-functionals, business change and quality assurance. All stories that require effort from the sprint team and need to be scheduled as part of sprint planning or Program Increment planning are shown on the Story Map. This reduces the chances of unplanned work entering a sprint and impacting the team’s velocity.

· Our map shows the confidence level the team has in their understanding of the requirement and their ability to accurately assign a story point value to the story. These help the Product Owner and team focus on the areas where additional clarity is required.

· Our map shows the story points assigned to each story and the increment/sprint that the story is assigned to. If you are trying to control your product’s scope to maintain a fixed go-live date then the map can be used to help the Product Owner with prioritisation decisions. If your Program Increment or last few sprints before a go-live are full then the impact of introducing a new must-have story can be assessed using the map. It provides a mechanism to quickly assess the options of accommodating the new story and see which element of my User Journey is impacted by my decision eg. can we move a story of equal size to a future release to accomodate the new-must have, or can we re-access a story/stories carrying a high number of story points to accomodate the new story.

· Our colour coding of completed stories provides a quick visual indicator of team’s progress. As a Product Owner I can visualise how my User Journey is being fulfilled by the delivery of each story.

It might seem a lot of work to create and maintain a User Story Map, particularly if you are attempting to produce it by hand. However there are tools and add-ons to Jira that can be used (https://www.featuremap.co/en, https://community.atlassian.com/t5/Marketplace-Apps-Integrations/How-to-create-a-story-map-in-Jira-Software/td-p/614717)

And from my experience the advantages of maintaining a User Story Map are well worth the slight overhead of producing it and it can often be produced and maintained by several members of your sprint team ( Scrum Master or three Amigos) rather than just one.

So in answer to my original question ‘How do you convey and manage the scope of your product, and what tools do you use to monitor and govern your progress towards its delivery deadline ?’. Hopefully you might consider adopting a User Story Map for your product and gain the same value as we do with ours.