Helpful Sites for Writing Better User Stories and Use Cases

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.

Read the rest at

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.

See more at:

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.

What is the difference between a UseCase and XP’s UserStory?

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:

Author: John Conley III

I am a technology and business consultant who provides state of the art software design services to rapidly growing and mature organizations using cutting edge technologies. Information Technology Professional with over 20 years of industry experience as a Software Architect/Lead Developer and Project Management Coach using service oriented (SOA/EIB) view of the software development process (Use Case/Story View, Class Design View, Database Design View, and Infrastructure View) and software design (Model-View-Controller based (MVC pattern/framework)). Coached PMs on various aspects of task and resource management and requirements tracking and tracing, and even filled in for PMs. Led teams of varying sizes mainly from the architect viewpoint: translating non-technical requirements into concrete, technical components and work units, identifying and creating reusable frameworks and design patterns, creating skeletal IDE projects with MVC wiring and config files, assigning app tiers or horizontal components to developers, making sure test team members have use cases and other work unit inputs to create an executable test/quality assurance plan, organizing meetings, ensuring enterprise standards and practices are adhered to, enforcing any regulatory and security compliance traceable from requirements/Solution Architecture Documents (SADs) all the way down to core classes in code, and so on Expertise includes designing and developing object-oriented, service/component-based software systems that are robust, high-performance and flexible for multiple platforms. Areas of specialization include Internet (business-to-business and business-to-consumer) e-commerce and workflow using Microsoft.NET technologies (up to current Visual Studio 2010/.Net Framework 4.0, MVC3/Razor View Engine, LINQ), TFS, Sharepoint 2007 (Task Mgmt, Build Script), Commerce Server 2007/2002 (basket and order pipeline), ASP.NET, ADO.NET, C#, Visual C++, Visual Basic.NET) and Java EE/J2EE, service oriented architecture (SOA) and messaging (MSMQ, MQSeries, SAP message handling) and more abstract enterprise service bus (ESB) designs, best patterns and practices, telecommunications and the offline processes of the enterprise. Provide detail estimates on budgets, guided design and development tasks with offshore teams, technical assessments of third party software tools and vendor selections, project/iteration planning and spring product backlogs, and level of effort for statements of work (including for offshore based development teams), including executive summary presentations as needed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s