The document discusses how to write user stories at the appropriate level of detail for product backlogs, release planning, and sprint planning in agile software development. It explains that stories should contain just enough information to allow teams to estimate their size relative to other stories for backlogs, and understand what is required to complete the story for sprints. Stories that are too large can be split into smaller stories, while too small stories can be combined. Epics are large compound or complex stories that need to be broken down before being worked on. Acceptance criteria and testing are also discussed.

1. How to know when a story is at the right level of detail
Stories are vital to the Product Backlog, Release Planning and Sprint Planning and delivering something
of commercial or operational value iteratively and incrementally.
The more experience you have with writing stories, and estimating story size using a relative unit of
measure, the easier it will become for you to recognize when a story is at the right level of detail.
When you are sizing your stories, at the Product Backlog level, a story should contain just enough detail
for the team to be able to estimate its relative size to other stories.
When estimating your stories, at the Sprint Backlog level, a story should contain enough detail for the
team to be able to determine what the solution involves or what it will take them to deliver the story.
Characteristics of good stories
Stories are not written contracts or detailed requirements that the system-software must implement.
Stories are short descriptions of functionality, the details of which are to be refined in a conversation
between the Product Owner (aka, the business or customer) and the development team. The challenge
comes in learning to include just enough detail.
At the time the story is written some important details may become known, they should be included as
acceptance criteria for the story, as shown in Figure 1.0.
Figure 1.0 – A story and related acceptance criteria
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 1 of 5

2. When you’re discussing a story, and the story seems to be getting larger and larger (”what about x?”;
“have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple
version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it
simple. Then, break out all the variations and complexities into their own stories. So, for example, this
story:
As a user I can search for flights between two destinations
We can disaggregate1 this story into simple stories by splitting off variations like:
As a user I can search for flights between two destinations specifying a max number of stops
As a user I can search for flights between two destinations including nearby airports
As a user I can search for flights between two destinations using flexible dates
etc.
The fact of the matter is some stories can be too big, some can be too small, and some can be just right.
Story size does matter because if stories are too large or too small you cannot use them effectively in
planning. Stories that are too big are called Epics. Epics are difficult to work with because they
frequently contain multiple stories.
For example, in a travel reservation system, “A user can plan a vacation” is an epic. Planning a vacation
is important functionality for a travel reservation system but there is just too much functionality in this
story; which will result in increasing the teams effort spent estimating the story size and degrade the
accuracy of the story estimate.
An epic should be split into smaller stories. Epics typically fall into one of two categories:
• The compound story
• The complex story
A compound story is an epic that comprises multiple stories. For example, a job posting application may
include the story “A user can post her resume.” When the team talks more about this story with the
Product Owner, they find out the “post her resume” actually means:
• that a resume can include education, prior jobs, salary history, publications, presentations,
community service, and an objective
• that users can mark resumes as inactive
• that users can have multiple resumes
• that users can edit resumes
• that users can delete resumes
1
Disaggregation refers to splitting a story into smaller, easier-to-estimate pieces; page 55, Agile Estimating and
Planning, by Mike Cohn
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 2 of 5

3. However, disaggregating an epic this way may go too far in the opposite direction, turning it into a
series of stories that are too small.
For example:
• A Job Seeker can enter a date for each community service entry on a resume
• A Job Seeker can edit the date for each community service entry on a resume
• A Job Seeker can enter a date range for each prior job on a resume
• A Job Seeker can edit the date range for each prior job on a resume
Generally, a better solution is to group the smaller stories as follows:
• A user can create resumes, which include education, prior jobs, salary history, publications,
presentations, community service, and an objective
• A user can edit a resume
• A user can delete a resume
• A user can have multiple resumes
• A user can activate and inactivate resumes
There are normally many ways to disaggregate a compound story. The preceding disaggregation is along
the lines of create, edit, and delete, which is commonly used. This works well if the create story is small
enough that it can be left as one story. An alternative is to disaggregate along the boundaries of the
data.
To do this, think of each component of a resume as being added and edited individually. This leads to a
completely different disaggregation:
• A user can add and edit education information
• A user can add and edit job history information
• A user can add and edit salary history information
• A user can add and edit publications
• A user can add and edit presentations
• A user can add and edit community service
• A user can add and edit an objective
Unlike the compound story, the complex story is a story that is inherently large and cannot easily be
disaggregated into a set of constituent stories.
If a story is complex because of uncertainty associated with it, you should estimate the size of the story
at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89). Then in your sprint have an
investigate story to more clearly understand what the solution involves to deliver this story.
For example, suppose the team is given the story “A company can pay for a job posting with a credit
card” but none of the developers has ever done credit card processing before. The team would then
decide to disaggregate the story in the sprint like this:
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 3 of 5

4. • Investigate credit card processing over the web
• A user can pay with a credit card
In this case the first story will send one or more developers on a spike. When complex stories are split in
this way, always define a time-box around the investigative story, or spike2.
Complex stories are also common when developing new or extending known algorithms. For example, a
biotech company had a story to add novel extensions to a standard statistical approach called
expectation maximization. The complex story, as part of sprint planning, was divided into stories: the
first to research and determine the feasibility of extending expectation maximization; the second to add
that functionality to the product. In situations like this one it is difficult to estimate the size of the story,
so once again size the story at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89).
Stories must also be written so as to be testable. Successfully passing its tests proves that a story has
been successfully developed. If the story cannot be tested, how can the developers know when they
have finished coding?
Un-testable stories commonly show up for nonfunctional requirements, which are requirements about
the software but not directly about its functionality.
For example, consider these nonfunctional requirements:
• A user must find the software easy to use
• A user must never have to wait long for any screen to appear
The preceding are not stories, they are details of a story to be captured as acceptance criteria associated
with a story or stories.
Sidebar
Acceptance criterion such as “a user never has to wait long for any screen to appear” is not
testable, because it says “never” and because it does not define what “wait long” means.
Demonstrating that something never happens is impossible. A far easier, and more reasonable
target, is to demonstrate that something rarely happens. This acceptance criterion could have
instead been written as “New screens appear within two seconds in 95% of all cases”; an added
bonus is an automated test can be written to verify this.
Summary
1. Ideally, stories are independent from one another. This isn’t always possible but to the extent it
is, stories should be written so that they can be developed in any order.
2. The details of a story are negotiated between the Product Owner and the team.
2
A spike is an experiment that allows developers to learn just enough about something unknown in a story, e.g. a
new technology, to be able to estimate that story. A spike must be time-boxed. This defines the maximum time
that will be spent learning and fixes the estimate for the spike.
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 4 of 5

5. 3. Stories should be written so that their value to the Product Owner is clear. The best way to
achieve this is to have the Product Owner write the stories.
4. Stories may be annotated with details, but too much detail obscures the meaning of the story
and can give the impression that no conversation is necessary between the team and the
Product Owner. One of the best ways to annotate a story is to write acceptance criteria for the
story.
5. When stories are too big, compound and complex stories may be disaggregated into multiple
smaller stories.
6. When stories are too small, multiple tiny stories may be combined into one bigger story.
7. Stories need to be testable.
Tips - experiences from using this approach
The more experience you have with writing stories, and estimating story size using a relative
unit of measure (1, 2, 3, 5, 8, 13, 21, 34, 55, 89), the easier it will become for you to recognize
when a story is at the right level of detail.
When you are sizing your stories, at the Product Backlog level, a story should contain just
enough detail for the team to be able to estimate its relative size to other stories.
When estimating your stories, at the Sprint Backlog level, a story should contain enough detail
for the team to be able to determine what the solution involves or what it will take them to
deliver the story.
Epics are okay to have on your Product Backlog as long as they are stories at the bottom of your
Product Backlog (lowest in priority). When you are within 3 Sprints of these stories it is time to
disaggregate them.
It is okay and expected, for novices during their first couple of Sprints, to discover your
estimates were either really low or really high.
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 5 of 5