What are User Stories?
User stories the standard method of documenting product requirements in agile software development. Let’s talk about how to optimize them.
Note: This post, originally written in October 2008, was extensively
updated rewritten in November 2013.
User stories consist of a need, the person with the need, and the objective that can be achieved by meeting the need. This provides context that a simple “The system shall…” statement cannot. This ensures that when starting an individual user story, the development team has enough to understand its purpose and commence action.
User Story Template
As a [role/persona]
I need to [needed function]
So that [reason]
This is the prototypical user story format, extended with an “Every” phrase to document frequency.
The “As a ____, I need to ____ so that _____” format is conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too much.
User stories are not intended to contain every detail about a feature. User stories are intended as a starting point for discussion.
It is helpful to include boundaries around the end results of a story by including acceptance criteria. Acceptance criteria are statements that must be true when the functionality is developed. This allows the product owner to describe the end result, without describing how the result was obtained.
Who wants it?
User stories should be validated against, if not entirely based upon what real users want. Gojko Adzic writes that writing “as a user” doesn’t make it a user story:
The lie starts with the whole premise. “As a user, I want to register”…. No I don’t. As a user I don’t want to give my private information to another site, have to argue with some arbitrary fascist filter about which combination of letters and numbers is strong enough, try to guess what’s written on some random distorted image, and then have to remember another set of fake privacy answers. That sentence might be in a user story format, but it’s far far from a user story.
It’s not enough to write the product requirement “from the perspective of” your real user or even your personas. You need to actually talk to the real users and understand them!
As a product owner, because of the number of user stories in a project and the intense focus required on each individual story, it’s easy to become lost in the individual story and lose sight of the end goal. A good product owner documents how the user story relates to others in the product backlog using a variety of tools.
Roman Pichler’s Product Canvas addresses this by providing several elements of context necessary to convey the vision of a product:
….epics to describe the product functionality, storyboards to capture the user interactions, design sketches to illustrate important design ideas, and a performance constraint. It provides a coarse-grained but holistic description of the product.
Pichler’s board also contains user personas which help drive user-centered design.
Without a “holistic description of the product,” it’s very easy to go wildly off course. Everyone involved–business stakeholders, product developers, and product managers themselves will offer hundreds or thousands of suggested improvements which may or may not align with the purpose of the product. Since no team has unlimited time, no team can afford to act on every good idea.
Proper definition is the product owner’s job
Are your user stories effective?
It’s the product owner’s job to make sure stories are properly defined. Are all the acceptance criteria documented? Have they been vetted by the team (or at least a techincal lead) in a backlog grooming session? If not, starting the story can result in slower velocity as the questions are answered as part of the development time.
Pichler wrote in the past about a “Definition of Ready (DoR)” that can help ensure a team doesn’t start a story it isn’t ready to execute on. An excerpt:
A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are simply attached to the story…
As it turns out, it’s often stated that the single biggest contributor to agile team velocity is user story readiness. Teams have to work on the user stories in the backlog in order–so they generally won’t skip down to the first “clear” item. The product owner will push for the top item as well, which means time in the sprint will be spent clarifying the top items as they are built (or rebuilt). This slows the team down.
How do you tell a user story is any good?
In practice, a user story is generally considered “good” if it results in software that satisfies users. But sometimes, there’s so much lag time or so many other stories involved that it’s really hard to dissect a product to determine the impact a single story had on the system.
Another way to think about user story quality is whether the engineering team was able to take action on that story with minimal questions, or whether a lot of detail had to be clarified after development began. Marty Cagan advocates the concept of dual-track scrum, in which teams do significant prep work in advance of building features in order to ensure the features built meet user needs.
Mike Cohn, in his book User Stories Applied, argues that user stories need to meet the INVEST criteria:
All of these are important, but after years of practice, I’ve come to the conclusion that Small is perhaps the most important of Cohn’s criteria.
The reason is that teams tend to thrash around exponentially because of unclear requirements. One way to counteract churn is to ensure the stories are clearly defined and small in scope from the beginning.
Teams I have worked with assign the largest point value to a “new concept” in the product — where new infrastructure is required along with new thinking. In addition, anything that they can’t get their heads around automatically wins the largest T-shirt size available, due to uncertainty.
One way to reduce uncertainty is to insist upon small stories. I’ve heard of companies where given available sizes of Small, Medium and Large, nothing bigger than a Medium was allowed. The benefit here was that items with too much uncertainty were sliced down to more manageable bits of work by the product owner.
In my current environment we haven’t made this a rule, but smaller stories are encouraged.
How are stories decomposed or broken down?
There are numerous ways to break stories into smaller ones, but the metaphor I most agree with is vertical slicing.
Rather than building a little of every part of the system–but not enough to be useful–the idea is to build end-to-end value, addressing only a narrow use case but addressing it successfully.
Plenty of bandwidth has been spent understanding how a product owner identifies the features needed in a product for internal customers or for commercial software. Some companies try to do that up front; many are moving to an iterative approach.
Other posts on this blog cover this in more depth, and more will be written.
At the most granular level, user stories define the work to be done. Properly defined user stories are the way to ensure the development team operates at peak performance.