Advantages of the “As a user, I want” user story template
In my user stories book and in all my training and conference sessions on user stories I advocate writing user stories in the form of:
“As a <type of user>, I want <some goal> so that <some reason>.” While I consider the so-that clause optional, I really like this template. At a conference, someone asked me why. Because I get that question fairly often, I want to give three reasons why here:
Reason 1 Something significant and I’m tempted to say magical happens when requirements are put in the first person. Obviously by saying “As a such-and-such, I want …” you can see how the person’s mind goes instantly to imagining he or she is a such-and-such. As for the magic, Paul McCartney was interviewed and asked about why the Beatles songs were so amazingly popular. One of his responses was that their songs were among the first to use a lot of pronouns. Think about it: She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. His point was that these helped people more closely identify with the songs. I tried briefly to find a source for this interview tonight and the closest I found was this. The information in that reference fits my recollection of hearing McCartney says this during a radio interview in 1973 or 74 that I assume was recorded when the Beatles were together.
Reason 2 Having a structure to the stories actually helps the product owner prioritize. If the product backlog is a jumble of things like: • Fix exception handing • Let users make reservations • Users want to see photos • Show room size options
… and so on, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is.
Your use cases are only as effective as the value someone’s deriving from them. What seems obvious to you may not be to your developers or customers. The success measurement for an effective written use case is one that is easily understood, and ultimately the developers can build the right product the first time.
A great way for writing effective use cases is to walk through a sample use case example and watch how it can be leveraged to something complex. By absorbing the meaning of use case diagrams, alternate flows and basic flows, you will be able to apply use cases to your projects. In some of the tips below, we’ll use eBay features for example use cases.
Before we get into this blog post for writing effective use cases for software development and product management, let’s quickly define a use case. If you had to find a single word it’s synonymous with, I suppose you could say “scenario”, but it’s really much more than that. It’s the particular types of scenarios that are made up activities. When you’re talking to your friends about a new obscure start-up, a great question that I like to ask is “What’s the primary use case for the customer?”. It puts someone on the spot to tell a story from the customer’s perspective from customer acquisition, to purchase, and on to engagement. Anyway, now let’s get on to writing up some use cases!
Tip 1. When creating use cases, be productive without perfection
Tip 2. Define your use case actors
Tip 3. Define your “Sunny Day” Use Cases (Primary Use Cases)
Tip 4. Identify reuse opportunity for use cases
Tip 5. Create a use case index
Tip 6. Identify the key components of your use case
Tip 7. Name and briefly describe your use case
Tip 8. Create the use case basic flow
Tip 9. Create the use case alternate flows
Tip 10. Produce your use case document
Tip 11. Sample Use Case Model Diagram
Tip 12. Do you need User Stories?
Tip 13. Agile Development with Use Cases
Are use cases agile? They’re sometimes regarded as the lumbering, heavyweight cousin of user stories – the requirements technique favored by agile teams. Use Cases ARE Agile. No… really. Being agile is an attitude and an approach, while use cases are simply a structure for organizing requirements. There’s nothing about use cases that make them ill-suited for agile teams. Rather, it’s the way that use cases are typically written that is NOT agile (that is, written completely up-front). So, “Are use cases agile?” is the wrong question. If you want to stay agile, but need something more than a user story, the question to ask is, “How can I write use cases in an agile manner?” Here are four steps to get you started.
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. This article covers the following topics:
1. Introduction to User Stories
A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it’s a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts.
Use cases are a popular way to express software requirements. They are popular because they are practical. A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction.
Use cases are simple enough that almost anyone can read them. Even customers or users can read use cases without any special training. However, writing use cases takes some practice. It is not difficult to start writing use cases, but really mastering them takes training, practice, and insight.
No single use case specifies the entire requirements of the system. Each use case merely explains one particular interaction. An organized suite of use cases and other specification techniques are needed to fully specify the software requirements.
The figure below illustrates where a use case document fits into the overall software requirements specification (SRS) and how it relates to other documents. This white paper focuses on the yellow “Use Cases” box. Ideally, your use case document is just one part of an overall set of project documents. But, don’t worry if you just want to jump straight into writing use cases: this white paper focuses on them.
User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.
This is a common question, and not one that has a generally agreed on answer. Many people in the XP community consider stories to be a simplified form of use cases, but although I used to hold this view I see things differently now.
Use cases and stories are similar in that they are both ways to organize requirements. They are different in that they organize for different purposes. Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.
Origins User Stories originate with Extreme Programming, their first written description in 1998 only claims that customers define project scope “with user stories, which are like use cases”. Rather than offered as a distinct practice, they are described as one of the “game pieces” used in the “planning game”. However, most of the thrust of further writing centers around all the ways user stories are unlike use cases, in trying to answer in a more practical manner “how requirements are handled” in Extreme Programming (and more generally Agile) projects. This drives the emergence, over the years, of a more sophisticated account of user stories. cf. the Role-feature-benefit template, 2001 cf. the 3 C’s model, 2001 cf. the INVEST checklist, 2003 cf. the Given-When-Then template, 2006 Signs of use the team uses visual planning tools (release plan, story map, task board) and index cards or stickies on these displays reflect product features the labels on cards that stand for user stories contain few or no references to technical elements (“database”, “screen” or “dialog”) but generally refer to end users’ goals – See more at: http://guide.agilealliance.org/guide/stories.html#sthash.QAEt5kk1.dpuf
- We vs they: agile testing (tisquirrel.wordpress.com)
- How to split user stories – London Agile Discussion Group (agileworldblog.wordpress.com)
- An Agile Life- Part 1 (brendasmull.wordpress.com)
- Lessons learned how to do Scrum in a fixed price project (trifork.com)
- A Lack of a Shared Understanding (thecriticalpath.info)
- Epics, Story Mapping and Kanbans Make a Unified Agile View (keeping-agile.com)