Today we have a guest post from Jeremy Berriault.  Jeremy is a columnist on the Software Process and Measurement Cast and the author of the QA Corner blog. He is a professional tester and is currently a QA manager.  During a recent recording session, Jeremy and I talked about using story maps in testing.  That discussion resulted in this guest post.

Guest Post: Story Maps for Testing

The use of story maps has been picking up speed and the use of them have proven to be a good tool to start linking items up so that there are no surprises down the road.

From a testing perspective, I feel, this is something that should be looked at as not only helping see what the bigger picture is, yet also identifying areas to simulate early so that the teams can prepare.

Barry Overeem’s article https://www.barryovereem.com/the-user-story-mapping-game/, has a nice description of how it all works, along with a nice picture of what one would look like. Yes, the intent is to ensure that features are not done sooner than any other dependent tickets, which is a good thing. When I talk about setting up simulations, it is more about not waiting of those features if the scheduling of the development in the release is not fully aligned. From a quality standpoint, it is making sure things are smooth.

Now imagine using string (well virtual string if your map is online) to connect the tickets along with the deliverables. It could end up like a conspiracy theory wall. Which in the end it is ok since you will now have a good path of where and when you can focus attention and see where help might be required early.

For me I see this as another tool in the toolbox to get things straightened out. I remember the days of 80-page requirement and doing something like this to identify where I need to plan things out and when. A nice graphical view allows for easier consumption and not missing something. Which helps with early detection and making the appropriate changes.

The way I see it there shouldn’t be one ticket that is not linked to another in some way. Something always builds onto another one. Same as how I talk about test case building. To keep it modular and easy to use, a test case should have the output of a different case to feed into another. If you think about it you will have only one test case where that would not happen, the initial main case to get the system going, unless you get granular (which is a bad idea for testing functionality and should be focused on Unit testing).

From a test planning view, you would have a second “map” of just test cases that should overlap over the product story map. With the exception that there will be a lot more connections on the test case map. Now all that is left to do is plan out the simulations (Data, SOA, Files etc…) and get to work.

Both maps together would then help reduce the risk of having an “oh crap” moment late in the release cycle when something new is discovered or not thought of. Work smarter not harder, correct?

 

A Map

Map!

In response to the recent articles on story mapping, I was asked, “When don’t I use a user story map?” As with many powerful tools, it is easy to want to use story maps in almost every situation; however, there are a few scenarios where story maps are at best overkill or at worst might be wasted overhead.

Small, low complexity efforts. Work that only impacts a small piece of functionality rarely needs the overhead of a story map.  While every team/person has a different perspective on what is small or low complexity, I suggest one basic rule, if the output of the work is a product, feature or application, however small, create a story map to guide the work.

Disjoint accumulations of work. A classic approach in many development organizations is to gather several pieces of work together (often only loosely related) and then to call that work a project.  The whole package might be large and/or highly complex; however, the lack of cohesion between each piece of work is a problem. Creating a story map in this scenario makes little to no sense.

Operational work. A story map for installing servers or scanning documents does not make sense.  In operational scenarios value stream or process mapping are significantly more useful.

A request to all blog readers and podcast listeners –
Starting next week we are going to start a process of picking both the most overused and favorite agile saying.   I have a list, but before we start, if you have a favorite please add it to the comments or email it to tcagley@tomcagley.com.

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.