Writing a User Story for a scrum product backlog is easy ... if you understand how. These slides were put together for a PHPLondon lightening talk which was given on the 1st July 2010.

1. Effective User Stories
Introduction
The product backlog is the root of the scrum process. Ideally, every piece of work we do should
come from the product backlog, have been well written with acceptance tests that adhere to the
INVEST acronym. If the business wants a piece of work done, a user story should be created
and added to the backlog.
The better the user stories are on the backlog, the better chance development have of
estimating how large they are and how long they take. This makes creating a roadmap and
release dates for the software we produce MUCH easier!
I want a TPS report!
So, the boss wants a new report. He’s a very busy guy with his head in a lot of places but has
identified a need for a new report.
“I want a TPS report, please put it on the backlog!” the boss asks the product owner.
The product owner would then put this story on the bottom of the backlog and mark its size as
EPIC. This means it’s too big and ambiguous to estimate now and needs to be refined. At this
point the story could be better defined or broken down into smaller stories. This is what happens
next.
INVEST time in your user stories
Invest is a great acronym for helping you to write user stories, it goes like this:
Independent
Ideally, the story should not depend on other stories. While this is not always feasible, it makes
estimating and prioritising much easier.
Consider a story that asks for the login to a new application to be written. The login might
depend on a data access layer that hasn’t been written yet. We could estimate the login story
based on the assumption that the data access layer had been written. But if we were then asked
to do the login as a matter of high priority, there is no way we could ever deliver “potentially
shippable code” by the end of a sprint. Then, creating a story just for the data access layer
doesn’t provide any visible value to the business. So the solution is to write a story as a “slice”

2. of all the parts needed to deliver the login.
The login story would need to be re-written to INCLUDE some measure of data access layer,
even if it’s not the fully designed version.
Negotiable
The story isn’t an exact description of the task in hand. If appropriate, the business
requirements, functional spec and technical spec will spell out all that. The story itself should be
negotiable, meaning that collaboration needs to occur with the author of the story to flesh it out
a bit and discover exact requirements with conversations over time.
Look at stories as a catalyst to start a conversation.
Valuable
A story should have value. If it doesn’t then why would we bother doing it? Once the business
understands that user stories are both negotiable (not set in stone) and must provide value, it is
much easier for them to write.
Estimable
Developers need to be able to estimate the size of a story, if they are unable to do this, then
either it’s a lack of domain knowledge, which requires collaboration and a conversation with the
story author, of it’s too big and needs to be split into smaller stories for easier estimating.
Small
Ideally, a story should fit into a sprint. Not to be delivered by one person, but by a whole cross-
functional team. If it can’t, it should either be broken down further or the sprint made longer (as
long as the story is INVEST). If you can’t fit a story into a sprint, then you can’t have potentially
shippable code by the review!
Testable
This doesn’t necessarily mean it should have unit tests, regression tests or QA tests passed.
This means that the story must have some way of someone being able to say “It’s done.” These
are called acceptance criteria, more on those later.

3. Lets write a story
As a ...
Who is going to be the intended audience for this piece of work? Often it won’t be the author of
the story. Especially if the product owner has written it. This is an important step as it allows you
research whether this story will provide value for the audience, or is simply a “nice to have” by
the author.
“As a middle management donk...”
I need ...
Here is where you define, loosely, what is actually needed. Try and make it as descriptive as
possible without going overboard and boring everyone to tears. It should strike a balance of
understanding between the business and the development team, so when referring to the story,
everyone knows what everyone else is talking about!
“I need an online report which allows me to add testing criteria for a particular product and have
a ‘pass’ and ‘fail’ button next to each criteria”
So that ...
This section is where we confirm that this story provides value. Simply putting “so I can do my
job better” doesn’t really give anyone any idea of what value this story provides. Something
along the lines of “So I can analyse the data to enable me to make a decision on whether or not
increase my bidcaps” does.
“So that, we have a digital record of all testing done, which is easily replicable and can be
modified.”
Acceptance criteria
OK, so we’ve written the story well, it defines the “who”, the “what” and the “why”. But, how do
we know when we’ve finished? The fact that a story is negotiable means the business could
negotiate until the cows come how, scope/feature creep is certainly something that can sneak
in.
So, we add Acceptance Criteria. We simply ask the business; “How do we know when we’ve
finished this piece of work?”. The acceptance criteria should be a bulleted list, it could come in
the form of questions that require a “yes” to know if they’re done:
● Can I add test criteria to my online TPS report?

4. ● Can I mark each criteran with a PASS or FAIL?
Or, as a list of statements:
● TPS Report has multi line test criteria
● TPS Report has “Pass” and “Fail” buttons next to each critria
It would also be acceptable to reference another document:
● Report looks like mock up supplied by designers;
● Report data is displayed as defined in Business Requirements;
● Getting to report should follow process flow as laid out in “Logging into system and
authenticating”.
This also means that the acceptance criteria shouldn’t look like a functional spec. They
shouldn’t contain explicit instructions for accessing the particular feature, just whether the
particular feature works.
Conclusion
Writing user stories shouldn’t be difficult. The import thing to remember is collaboration with the
business. Poorly written user stories with badly defined acceptance criteria make everybody’s
job much harder in the long run; poker planning becomes long and drawn out, estimating is
almost impossible and by the time we get to planning, a badly written user story might actually
be hiding more work than we’d estimated for in the first place and our estimation was woefully
wrong.
Effective user stories with well defined acceptance criteria form a solid foundation of the work
we are asked to do. The sooner we know accurately what it is the business wants, the better
chance we have of being able to deliver a potentially shippable chunk of code for the sprint
review!