ser 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.
|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.|
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 storyby 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.
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.
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.
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.
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.
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.
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.
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.