Agile Story Map


26955153324_91f40a31cc_k

How the big picture gets made…

A high-level narrative or story is a good first step in the process of turning an idea into something that delivers real business value.  However, it is only a step along the path through the backlog onion.  Software development (including new development, enhancements, and maintenance work) requires translating the big picture into a product backlog that includes features and epics.  As work progresses the backlog is further decomposed and groomed into user stories and tasks.  The process of moving from any big picture to a backlog in software development follows a predictable pattern.    (more…)

Stories of all sorts

Stories of all sorts

Almost all projects are some combination of functional requirement (needs of the user), technical/architectural requirements (needs of the systems environment) and non-functional requirements (e.g. branding, maintainability and usability needs). In order to successfully deliver any project the team needs to meet all of these requirements. Classic Story Maps focus only on user stories.  However, projects that incorporated all of the different units of work to into their Story Map find that it is a more effective method for prioritization and release planning.  Using an Agile Story Map, projects fare better using a single, visualizable backlog. This increases the focus on delivering the project as a whole, rather than as separate streams of work.

This is the basic process: (See this post for an in-depth discussion of the process to generate needs and user stories.)

  1. Gather a cross disciplinary team of 3-7 people.
  2. Have the team identify the marketable features of the project/application (on sticky notes).
  3. Have the team group/rearrange the sticky notes.
  4. Name each group.
  5. Arrange the groups left to right in the order that they would naturally occur.
  6. Review/walk the skeleton.
  7. Break each Epic or user task down into more detailed user stories or activities.

You need to add several steps to incorporate technical or non-functional requirement to the process. After constructing the initial Agile Story Map, which is generally comprised of just functional user stories, we need to add the technical and non-functional stories. The steps we add are:

  1. Refocus the cross disciplinary teams.  Walk through the definitions of architecture, technical and no-nonfunctional requirements.  Remind the team that goal is not to design or generate solutions, but rather to identify known needs or constraints.
  2. Review/walk the current, functional skeleton established in the first seven steps. (optional)
  3. Identify the high-level technical or non-functional requirements (similar to step 2 above).
  4. If any new Epics have been identified, break each Epic or user tasks down into more detailed user stories or activities.

Special note on non-functional items:  Non-functional requirements are not generally separate units of work, but rather attributes that describe technical or functional support. Non-functional requirements include the “ilities” (e.g. usability, maintainability and others) and can be easily incorporated in to the definition of done and/or story-level acceptance criteria.

The controversy with this implementation of Agile Story Maps is not that there are units of work that are technically and architecturally focused, I think that if you have ever run a project that this is evident.  Rather the controversy is when these types of needs are identified in the process and whether they should be incorporated into the Agile Story Map. Story maps are a tool to prioritize and plan.  Agile Story Maps are tools that you and your team can use if you find it useful to include more than users stories.

Personas in action!

Personas in action!

Personas are a powerful tool to understand the people for whom we are building a project or application.  The more we can understand those we are trying to satisfy the more apt we are to deliver functionality that actually meets their needs.  Combining personas and Agile Story Maps significantly increases our ability to grasp the requirements and needs of complex projects by clarifying the requirements/needs/stories generation process.

How to Use Personas When Generating An Agile Story Map:

  1. Define the personas (or review, if you already have defined personas) that represent the typical types of users for the application you are building or maintaining (See Daily Process Thoughts, August 29, 2013).
  2. Break into teams of 3 – 7 (smaller the better). For example, if you have a group of eight it would be best to split the group into two teams of 4.
  3. Split the personas between the teams that you have.  Each team should start with personas that they understand and are familiar with.  If you have no one in your group that “knows” a specific persona, put it aside and find additional participants that have the knowledge you need.
  4. Personalize each persona by adding names of real people that play that role.  This grounds the persona in the behaviors of real people that someone in the group knows. Someone can say. “I know Jill, and she needs . . .” If the team can’t identify a real person that to attach to the persona they should put the persona aside. Try to add several names to each persona to help keep a broad perspective. (Time box activities 3 and 4 to a total of 5 – 10 minutes)
  5. As a team identify the application needs for the personas you are working with by asking the participants to answer the following set of questions for their personas. Keep going until they can think of nothing else to add.
    >>  What would persona do first when using this application?
    >>  What would they do next?
    Write each need on a 3×5 card or medium sized sticky note.
    (Time box this activity to 10 – 20 minutes.
  6. Arrange the needs into a workflow or timeline of user activities on a wall, a table or floor.
  7. Review each user need, create user tasks and details about those tasks. These will eventually become user stories. Write those on cards too, and stack them vertically under the corresponding user activity.
    (Time Box this activity to 10 – 20 minutes.)

If you are running a session with multiple teams it usually makes sense to rotate a portion of each team (one to two members) and then re-run steps three and five with the new team make-up. This helps ensure completeness.  I generally time box this step to half of the original time in order to reduce the potential for debate paralysis.

After completing this session restate the results of step seven in User Story Format (“As a <persona>, I want to <function> so that I can <business value>.”) and then use the prioritization technique discussed in Daily Process Thoughts, August 27, 2013.

Personas are a great tool to have in your Agile bag of tricks.  A basic person will include a name, a picture, relevant characteristics and business needs.  Even though each persona is a metaphor for a group of users, by attaching a name and a face they are personal enough to help us engage with the persona on a level a little more intimate than we would a user type. Personas are personal, they are memorable and they represent people like us – rather than clinical, generic user types. This personalization makes them useful for driving out requirements, or as a tool to help identify needs and activities to populate our Agile Story Maps. Can you create an Agile Story Map without using personas?  Of course, and in small project and applications, you probably do not need personas. But as the projects and applications increase in business complexity, personas help us to see the big picture.

One persona or many?

One persona or many?

Fleshing out the user needs is one of the most critical steps in the process of generating an Agile Story Map.  Sometimes it is easy to jump over the creation of user needs and the stories that are needed to satisfy those needs, and jump directly into the mechanics of building the Story Map, but you will not derive the same value in the end. Personas are an oft-practiced tool used to  help you focus on the generation of user needs and stories.

What Are Personas?

Personas are a metaphor for groups of systems users that were originally introduced by Alan Cooper. Roman Pitchler later suggested a template for a simple version of personas, which included: the persona name, a picture, behavioral characteristics, and business needs.  The first two categories help define the “who” part of the persona, while the rest describe the “why,” i.e. why the person would use the system. The concept of personas is used widely, inside and outside of IT.

The information used to define a persona varies by how the persona is going to be used. Thus there are many other, specialized versions of personas that include other data.  Examples of the other data include: capabilities, attitudes, involvement, age, location, likes and dislikes and technical comfort – just to name a few. I strongly suggest that persona you use be only as complex as it absolutely has to be. Use only the data that is relevant. For general IT projects, I generally use Pitchler’s template and then add location and technical comfort. (We will revisit this concept when we discuss gamification. There more complex personas may be needed.)  Always include a picture when defining personas.  Pictures help to draw in visual learners While I am not an artist, I feel that a hand-drawn picture is better than a photo to reinforce the idea that a persona rarely represents a single person, but rather is a metaphor for a group.

Mining or Defining Personas

Many Agile teams use User stories to delineate pieces of work.  User stories follow a pattern of “As a <user type>, I want to <function> so that I can <business value>.”  User type can be considered as generic starting point for defining a persona. If you use user stories, isolate the user types, group like user types together, give them a name and then complete the template for each persona.

Another place to start, if you have been using use cases, is to gather all of the “actors” that have been identified.  As with user types, group like actors together, name them and complete the template.

If you are not using use cases, user stories or any other user-centered documentation methods, start with a brainstorming workshop to identify the types of users and personas you and the software will be interacting with.  To help the session along, I use seed questions such as:

  • What departments will use this software?
  • What types of users roles are there?
  • What customers will interact with the software?
  • What are the goals type of customer trying to accomplish with the software?

When you have completed the brainstorming session use mute grouping (affinity diagraming) to cluster the roles.  Then name each distinct group and complete a persona template for each.

In Agile, personas are a tool that is used in many situations, such as developing user stories or generating an Agile Story Map. They can be used to focus the discussion of requirements, needs and stories on the types of people that will be interacting with the project or application. Because personas are named and tied to a picture, they are far less impersonal. It is easier for team members to feel a relationship.  The ability to relate to the people that the persona is a metaphor for improves our ability to put ourselves in their place and discover their requirements and needs.

La Sagrada Familia was a minimum viable product that is still being built

La Sagrada Familia was a minimum viable product that is still being built

An Agile Story Map combines three basic types of information: stories, workflow information and priority.  With the addition of velocity (i.e. how much work can be delivered), these three pieces of information provide the basis for release planning.  Release plans generally reflect one of two basic philosophies.  In the first philosophy, a release is based on the on a fixed amount of functionality. In the second, a fixed duration is used.  Let’s apply each these strategies.

Fixed Functionality Release

The first row underneath the marketable and architectural features, which contains the highest priority user stories, is called the “walking skeleton.” The walking skeleton represents a barebones version of the product or project. It should represent the lean concept of a minimum viable product; just the essentials.  If you were building a house, having a foundation would be a high priority unit of work and part of the minimum viable product. A finished basement playroom is not as high a priority, and not be part of the initial release or part of the minimum viable product.

One successful iterative strategy is for the walking skeleton to be the initial release.  Each subsequent release (or rows in our map) would flesh out the product. The process of iterative releases elicits feedback from real users to hone the backlog, so that subsequent releases will more closely reflect the user’s needs. Using the walking skeleton as a mechanism to trigger a release is a reflection of the functionality-driven release strategy.

Fixed Functionality Exhibit A

 Walking Skeleton and Fixed Functionality Release Boundaries

While the walking skeleton concept is most closely associated with new applications, it can also be applied to enhancement projects. In this case, the walking skeleton represents the minimum amount of new or changed functionality that would be useful to the customer.

Here are the steps to build the release plan:

Who: Whole team, lead by the Product Owner

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
  3. Repeat step two until all of the functionality in the map has been accounted for.

Remember that the Agile Story Map will evolve as the team builds a greater understanding of needs and receives feedback from stakeholders. Therefore, the release plan will change.

Fixed Duration Release

In the fixed duration release strategy, the team works as hard as possible for a specific duration and then releases the product. Release planning would be accomplished by applying the team’s velocity to a sized backlog. The release plan changes as velocity and the Story Map change.

Fixed Duration Exhibit

Walking Skeleton and Fixed Duration Release Boundaries

When developing a new application, this strategy only makes sense if the whole walking skeleton is released in the first release. As before, the walking skeleton represents the minimum viable product. The team would then work the highest priority work items, the user and architecture stories, and those completed in time would be packaged and released.

The main difference in process for building a fixed-duration release plan is the fixed date and packaging the work based on capacity (velocity or productivity):

Who: Whole team, lead by the Product Owner.

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
    • If the duration is more than the implementation window, either work with the Product Owner to refine the walking skeleton, add additional Agile teams or redefine the fixed duration.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  3. Repeat step two until all of the functionality in the map has been accounted for.

In both strategies the organization must weigh the business value of each release against the cost of development.  If the organization can make better use of the Agile team and other project resources, the work on the project should be halted and a new project begun.

The prioritization process in of Agile Story Mapping helps to identify a minimum viable product/walking skeleton.  Once a walking skeleton is identified Agile Story Maps provide a great platform for release planning. The mapping process supports both of the popular release strategies and methods that combine the two.  The visual nature of Story Mapping helps to ensure that the team and their stakeholders understand the impact of changes to the release plan as new stories are added or priorities are changed.

The map of the Great Wall is an information radiator.

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 Version 2

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.

The map of the  Inca Trail is its own story map.

This map of the Inca Trail is its own story map.

Product backlogs are lists of “work to be done” at different levels of granularity and priority.  They can be large and unwieldy. It is hard to see the big picture of the work, regardless of whether they are in analog form (e.g. sticky notes or 3×5 index cards) or are housed in a tool (e.g. Version One or LeanKit Kanban).  Story Mapping is a technique that teams can use to help visualize a product backlog. Importantly, it lets the stakeholders understand the big picture, prioritize work and plan releases.

The Story Map describes the big picture so that all the stakeholders can visualize the scope of the project. Jeff Patton, the creator of the Story Map technique said, “One of the most common complaints I hear from Agile teams is that they lose the big picture.”

The Story Map shows the context of what is being built and how it relates in the big picture. They arrange Epics, which are large stories, horizontally in a chronological or functional flow (left to right), then under each epic, there is a breakdown of the stories or tasks required. Visually you can look at any large story and see what is required or if you have missed something.

Simple Story Map

Example: Simple Story Map

Once the stakeholders understand the big picture the Story Map can be used to prioritize stories and to define a minimum viable product. Let’s say you were developing an application to house customer names and addresses.  One of the larger stories might be “a customer service agent needs to be able to maintain customer names and addresses.” The breakdown of smaller stories might be:

  • Display customer name and address
  • Add customer name and address
  • Change customer name and address
  • Delete customer name and address

The Map also helps expose the relationship between stories.  For example, you will need to be able to add a customer before you display a customer and you have to be able to display a customer before you can change a customer.  The Map helps identify those types of relationships.

The Product Owner and/or other stakeholders can assign priorities to the list, using a simple forced ranking techniques or more complex techniques in which they assign business value, and indicate whether specific pieces of functionality are required to support a specific release. The prioritized Story Map makes identifying the minimum viable product much easier. For example, let’s say the delete functionality was not prioritized very highly. With both the big picture of the functionality and an indication of priority, the team can have an informed discussion about whether the delete function is required in the initial release (i.e. is it part of the minimum viable product?).

Combining the Story Map, the minimum viable product and the team’s velocity provides a perfect platform for release planning and visualizing release plans. Groups of functionality can be gathered together based on the team’s velocity, which is a proxy for team’s capacity to identify sprints and releases. In practice, sprints and releases can be denoted using many techniques, from hand written notes on story card, colored flags or colored sticky notes. Given that the release plan is dynamic use a mechanism that causes you the least amount of rework.  For instance writing the release on the story card in indelible marker will generally cause you to rewrite cards as things change. The more visual you make the release plan, the easier it will be for everyone on the team to understand the ultimate goal and the path the project intends to use to get there.

Story Maps are a technique to help teams develop a big picture of their project, so they understand where they are heading.  The Story Map technique can be used as a tool to organize your backlog and then maintained to show progress.  Using the power of the visual organization, Story Maps, and the inferred relationships that the map helps expose, provide more information for stakeholders as they determine priority. Priority and the functional maps also provide a springboard to discuss what the minimum viable product will be and the release plan for the project.