User stories are a lightweight mechanism for gathering and verifying user requirements on Agile projects. Unfortunately, it is easy to lose the context of stories. Find out how techniques from user-centered design (UCD) can help avoid this problem.
User stories are probably the most popular tool for gathering user requirements on an Agile project. A user story represents some goal that a user would like to achieve, and collectively, user stories are a lightweight mechanism for gathering and verifying user requirements. Introduced to software development projects through Extreme Programming (XP), user stories have become standard on many Scrum projects.
According to Ron Jeffries, there are three key steps to capturing and implementing a user story:
- Card: This refers to the method of capturing the story—by writing it on a card. Not every detail of the story is captured on the card (see Figure 1).
- Conversation: The conversation with a user fleshes out details to gain a full understanding of what the project requires.
- Confirmation: The confirmation verifies that the implementation of the story meets the requirements.
Figure 1. Example User Story Card: User stories are often handwritten on cards. This example uses the format described in Mike Cohn's "User Stories Applied".
In the eyes of the customer, or product owner, each story will add a bit more value to the software. Unfortunately, it is easy to lose the context of stories and turn them into a meaningless list of feature requests. The challenges for Agile teams are to verify that they are writing good stories and to make sure they get the most out of them. This article explains how techniques from user-centered design (UCD) can provide solutions to these challenges.
INVESTing in a Good Story
William Wake coined a handy acronym to help identify the desirable qualities of a user story, I.N.V.E.S.T.:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Independent
To get the most value from user stories, they should be, as much as possible, independent. If all stories are kept truly independent, then you have much more flexibility when planning and prioritizing work. Tracking performance becomes simpler and more reliable as well. This is quite often the hardest goal to achieve, but it undoubtedly will have the biggest impact on the productivity and flexibility of any software project.
Negotiable
Capturing a user story should not be a hard contract. Keeping the initial definition of the story loose prevents you from over-analyzing requirements before you receive any feedback.
Valuable
A user story has to pay its own way. The product owner must be able to recognize the value of implementing a story. This requires you to write the story in the language of the product owner and to ensure that the product owner can relate to changes you make to the software.
Estimable
To be able to plan and attribute cost to software development, you need to be able to estimate user stories. Agile teams are increasingly using Kanban boards from Lean, where instead of estimating the work, teams track the time to complete a user story from conception to release and use this value to estimate the time it will take to complete new work.
Small
Agile processes are made up of short iterations. Scrum started around one month, but many teams have dropped this down to two weeks. A general guideline is that a user story must be able to be implemented within an iteration. This means that some stories, when initially conceived, may need to be broken down further so they can fit into an iteration.
Testable
A story must be testable. That is, the product owner needs to be able to verify that the story has been completed. Writing user stories for tasks that a user cannot verify is pointless.
The Importance of Context
User stories are the perfect tool for maximizing development throughput by keeping things manageable and separate. You should strive to write good stories that are small and can be prioritized and negotiated independently. Indeed, implementation strategy often goes to great lengths to avoid interplay between stories so that you can build things in parallel and not introduce a dreaded dependency.
However, there is a hidden risk associated with managing and communicating software creation solely through a collection of independent stories. Users don't judge software based on individual features; they experience the whole product and form their opinions based on this overarching experience. As the saying goes, "The whole is greater than the sum of its parts."
The Agile team's job is to figure out which solution is most suitable for users by understanding them and their context of use. This is the domain of UCD.
User stories provide Agile projects with independence and flexibility. A team can scribble a sentence on an index card to capture some thoughts about a product goal, drop it into the backlog, and then prioritize and refine it later. Because the team can swap stories around for implementation at almost any point, it is easy for the overall feel of the software to become fragmented. The implementation can jump from one section of the system to the other even within a two-week sprint.
All this agility makes it hard to retain a holistic vision of the solution. So, although the order in which a team delivers stories to the product owner is flexible, allowing the team to deliver the stories perceived as having higher value earlier, the team risks reducing the overall value of the software by providing a disjointed user experience.
To illustrate the importance of context when designing a solution for a user story, consider the example of building a project management tool for software development. Here is an example story from a manager who will use the tool:
As a manager
I want to know if a story is running over its estimated time.
So that I can proactively find out what the problem is and see if there is anything I can do to help.
This sounds like a pretty good story. It's fairly independent, it is certainly negotiable, it is valuable, it is probably estimable, and it seems small enough and testable. So what's the solution? Perhaps you can run a batch process that checks if a story recorded in the database has passed its estimated time. Perhaps you should show overdue stories on the manager's home page. Maybe it would be better for everyone who accesses the system to see overdue stories. What is the simplest thing that could possibly work? Which solution can you deliver earliest to the product owner to start realizing business value?
Now consider the following possible contexts of use:
- Context 1: The manager has a portfolio of projects. She drops in to see the team once a day to check on progress and gets a demo of the application most weeks. Maybe a way of printing out a report of stories that are at risk would be useful. She could to take the report along to the daily progress updates.
- Context 2: The manager is running a couple of projects with distributed teams in different time zones. She rarely gets to meet all members of the team face to face, but keeps a good relationship with a few key members of the team. Work is scheduled in phases, such as analysis, design, implementation, test, and release. This manager probably does not know what is going on day to day on the project, so she could benefit from some form of periodic update that would prompt her to get in touch with one of her teams.
- Context 3: The manager spends all her time on this one project. She spends most of her time in the same office as the team, providing background for stories and dealing with issues that the team are having. This user may want no notification at all. She relies on day-to-day conversations to identify whether a particular story is running over. All the information she needs comes from the daily standup meetings, and overruns are recorded on the wall. Highlighting overdue stories on the system may actually be counterproductive to her team.
Given the contexts of use (i.e., who the user is, what her activities are, and the context of those activities), you are able to make better implementation decisions. If you are building specific software for one of these users, then the solution is fairly straightforward. If you are developing a larger product that could meet all of these needs, you now understand the different contexts of use for different users and can start to see that a one-size-fits-all solution may not be appropriate.
Distilled User Research: Scenarios and Personas
UCD has a raft of tools and techniques for conducting user research. While the different research methods themselves are important to user-experience professionals, the key to integrating Agile and UCD is to ensure that the outputs of user research can be understood and communicated effectively within an Agile team. It is not necessary to communicate reams of research output, just the core essence.
Stephen P. Anderson summed up the essentials of experience design nicely on hisposter from IA Summit 2009 (see Figure 2): "It's all about People, their Activities, and the Context of those activities."
Figure 2. Extract from Stephen P. Anderson's Poster from IA Summit 2009: This extract from the poster shows the core considerations when considering experience design.
This article focuses on two classic information radiators from UCD (scenarios and personas) that help to effectively communicate people, their activities, and the context of those activities.
Embracing scenarios and personas can help Agile teams achieve a deeper understanding of their problem domain, which will improve the quality of user stories as well as the team's ability to implement them.
Communicating People's Usage Using Personas
The use of personas as a technique was popularized by Alan Cooper in his 1999 book The Inmates Are Running the Asylum. They are a very effective way of succinctly communicating research about the people who use your software. A persona typically includes a name and a picture. It often includes poignant quotes from user research as well as basic demographic information. Personas communicate common attitudes, frustrations, behaviors, and pain-points for a particular user group, all in an easily digestible and instantly accessible one-page poster. A persona is perfect for communicating a particular user archetype.
The main advantage of personas over more traditional methods of communicating about users is that they allow the team to develop real empathy with the user group. The picture and name help to put a human face to what could otherwise be treated as a list of demographic requirements (see Figure 3).
Figure 3. Example Persona: The main advantage of personas is that they allow the team to develop real empathy with the user group.
Communicating Context and Activities Using Scenarios
Scenarios are a way of helping to develop a detailed understanding of context and activities. They provide a framework for validating solutions against product requirements by bringing a "real world" activity-level description of the motivation and events that trigger tasks, as well as the users' flow as they move to achieve their goal. They can be documented as comics or concise narrative descriptions (see Figure 4), but they are best communicated verbally through role-play! Like personas, scenarios are created by aggregating and distilling insights from user research and analysis.
Scenarios focus on revealing the activities, blocks, touch points, mitigating circumstances, and interactions for a persona attempting to achieve a goal. They are an instantiation of a typical way that external forces might impact a user. The scenario storyline provides detailed context, which teams can use as a framework for exploring and experiencing the world from the user's perspective. The storyline serves to focus their thinking and challenge their preconceived notions.
Figure 4. Example Scenario Comic: Scenarios can be documented as comics or concise narrative descriptions.
Walking through or role-playing a scenario for a persona helps develop an understanding of when, where, and under what circumstances a user might need assistance in achieving a goal. Scenarios help to clarify the interplay between the persona and other systems, people, or organizational areas when the persona seeks this assistance. This helps teams keep focused on being effective within the context of the problem.
Building Solutions in Context
It is easy to recognize the benefits of user stories that follow I.N.V.E.S.T. Small and independent user stories encourage parallelism and maximize development throughput. However, without a shared understanding of the people involved, their activities, and the contexts of use, software development runs the risk of delivering value in a piecemeal fashion.
Supplementing user stories with distilled user research communicated through personas and scenarios will help Agile teams design software solutions that address the overarching experience as well as the specific user story.
This article was first published on DevX.com on 06/30/09
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.