Software Process and Measurement

The map of the Great Wall is an information radiator.

One of the most powerful concepts championed by the Agile movement has been the use of information radiators as communication vehicles.   Alistair Cockburn defines information radiators as “a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.” The goal of these tools is to increase access to information through transparency. Agile Story Maps are information radiators. The goal of a Story Map is to present the big picture of the project in assessable manner for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases. The first step is to create an Agile Story Map.

Agile Story Map Exhibit Version 2

Here’s the process (assuming that you’re not starting with an existing backlog).

Story Generation/Grouping

1. Gather a cross disciplinary team of 3-7 people that understand the purpose of the product. The team should include a mix of business and technical perspectives. The team size should constrained because as it grows the amount of discussion will increase faster than value.
2. Have the team identify the marketable features of the project/application.  I use silent brainstorming; each person silently writes down one marketable feature per sticky note. Once everyone has finished writing their post-its, have each person read their sticky note aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.
3. Next have the team group/rearrange the sticky notes without talking (affinity diagramming). Move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.
4. Name each group and place another color of sticky with that name above of the group. These are the Epics. The facilitator should lead this this step interactively.
5. Arrange the groups left to right in the order that they would naturally occur (user visible functionality or batch).
6. Review/walk the skeleton (term coined by Jeff Patton) to validate completeness in terms of user tasks or activities. The goal of this process is to identify holes in the story map based on the knowledge the team currently has available.
7. Break each epic or user task down into more detailed user stories or activities (I use a rule of thumb to break that stories should be broken into thin slices that can be completed during a sprint).

 Prioritization: There are several strategies for prioritization.

1. Business Value – assign business value to each story in the map. The Product Owner generally leads this effort. Prioritize the highest value first.
2. Risk and Complexity – assign a level of risk and complexity for each story.  The technical team members will generally have significant input into this discussion. Prioritize risk and complexity higher.
3. Perceived Dependencies – Tweak prioritization to reflect dependencies. The technical team members will generally have significant input into this discussion
4. Combination – Combine all three (my favorite approach).  Generally I prioritize by risk then value and then dependencies.  This engages the whole team in the discussion and front loads risk as a mitigation technique.

Based on the prioritization strategy, review each user story and assign it a priority.  I use the nomenclature of dollar value and a high, medium or low risk/complexity (i.e. $4000,H).  It is very difficult to precisely define the business value of each story, the actual dollar value is less important than assign a relative value for each story.  Knowing the relative value will provide the team with an understanding of which stories will provide more value. After assigning a value to all stories, sort each list from highest to lowest and roughly aligning stories of similar value.  When two stories have the same or nearly the same value they will be placed together (example in Column three in the exhibit above).

Story mapping is a relatively simple process that organizes the backlog. The story map is an Agile information radiator because it provides the team and stakeholders with information with them having to ask or dig. An Agile Story Map provides the big picture of the application and the priority of each of the stories.  Tomorrow we will use the prioritized map to generate a release plan.