Story Mapping in SAFe

A backlog is essentially a one-dimensional list of requirements. This list does not convey a lot of information. There is no notion of workflow which makes it extremely difficult to recognize gaps in requirements. Story mapping visualizes requirements in two-dimensional space which helps in the discovery of gaps in requirements, grasping the progress of value delivery, prioritization of requirements for a hierarchy of requirements. 

In a small engagement where only one team is working, Story Map is quite simple to construct and evolve. 

In a single team scenario Story Map may look like:

 Figure: Functionality View of a Story Map

In case of big engagements few complexities arises:

1. Hierarchy of the requirements: It should also be noted down that in any enterprise-class engagement, requirements form a hierarchy (Epics --> Features --> Stories). 

Figure: Hierarchy of Requirements

2. Multiple teams working in parallel to deliver value: In any enterprise-class engagement multiple teams work in alignment with time limitations and business & technological constraints to deliver value.

Figure: Multiple teams in a collaborative environment to deliver value

3. Scaling Framework constraints: Almost all scaling frameworks impose some constraints (and/or suggestions) which affect Story Map. For example SAFe framework, there are few recommendations and suggestions which affect the structure of Story Map: 

• Size of a Story --> To be delivered by a single team in a single Iteration
• Size of a Feature --> To be delivered by a single ART in a single PI duration
• Size of an Epic --> To be delivered by a single Value Stream in couple of PI duration
• Lean Startup style development using MVP and MMF
• Release may follow a predetermined Release Cycle or Release on Demand

Keeping above in view, lets’ construct a Story Map for an engagement which is following SAFe framework with a periodic release.

Construction of a workable Story Map

Our engagement is about to start.  You have some ideas around the “WHAT” part of the product though these ideas may be in a fluidic state.

Stage 1: In starting, few big initiatives and epics are known. Write each Epic on a big sticky note and paste them in a horizontal line on the wall.

Figure: Epics on the wall

Stage 2: It is time to add some details. Assemble Product Managers, Architects, Systems folks, Product Owners, DevTeam members, SMEs, and anyone who can contribute in the requirement discovery (Business as well as technical) in front of a big wall. One of the SME steps-up and starts narrating a story of activities they would perform to solve the problem for which you have decided to create a product. As SME is telling the story, armed with Sticky notes and markers few of the assembled persons start writing those activities on the wall. The arrangement of sticky notes should be left to right depicting actions to be performed by a user (as SME is narrating) to accomplish some job.

Figure: Epics and the Actions

Stage 3: As momentum builds up more than one person starts narrating stories from various perspectives as well as technical folks start pitching for NFRs and other technical requirements. Instead of one group, the room will witness various small fluidic groups all working on different aspects of the requirements. 

Once a substantial number of requirements are collected, it is time to bring in some order. A couple of persons can volunteer to remove duplicates and group the sticky notes into groups which will be represented as Feature.

 

Figure: Requirement hierarchy

Stage 4: It is time to group the requirements into the Features and Stories under the identified Epics. Certainly, you will find some holes in the requirements; plug them if possible.

Figure: Story map – First Cut

Stage 5: It is time to figure out a MVP. Pause!!! Can you figure out a MVP out of nowhere? NO, we need to categorize the Features (yes, Stories as well) using Kano or Moscow model.

Figure: MVP and MVA

It is time to mark MVP on the Story Map.

Figure: Story Map and MVP

Hurry! You have a pretty good Story Map to start with.

To facilitate such a fluidic workshop, you will need an experienced facilitator.

Now we have a workable Story Map as well as identified MVP, we are good to start our PI Planning meeting.

Continual evolution of Story Map

Now you have a workable Story Map, what’s next?

The purpose of Story Map is a two-dimensional visualization of backlog, so planning for maximum value delivery can be performed in a collaborative environment.  Story Map is never static, it is a living artifact. It keeps on evolving

.

Story Map and PI Planning meeting

During Pre PI Planning meeting and/or refinement sessions in current PI for upcoming PI, Agile Teams, Architects, PMs, Shared Services, and System Teams update the Story Map. 

At the end of PI Planning meeting, Story Map should represent the commitments made by Agile, System, and Shared Services Teams.

Figure: Story Map with PI commitments

Each Agile, Systems, and Shared Services team will maintain a part of Story Map also every team in an ART is responsible to maintain the whole of Story Map.  Each Agile, Systems, and Shared services team should mark its iteration commitments by drawing a box around stories committed in iteration planning.

Figure: Story Map with Teams’ commitments

Release planning

As Story Map very clearly depicts work done and in progress, it becomes comparatively easy to plan a release using it. The Features to be released in a particular release are boxed in a Release Box.

Figure: Story Map with Release Plan

More value addition in Story Mapping

With a little imagination, you can contextualize a Story Map.

 

a. Put wireframe next to the relevant areas of a Story Map
b. Use small stickies’ over story stickies’ to mark NFRs, Personas, refactoring target stories, etc.
c. Use threads to depict dependencies (actually you can combine dependency board in a Story Map).
d. Mark features as part of MVP or Minimal Viable Addition (MVA) to an existing product