Agile Story Writing

What You’ll Learn in this Presentation:
• The basics of user stories.
• How user stories fit into the overall Agile planning process.
• How to write a user story.
A story card example
2

3
Why is it so Difficult to Determine Software Requirements?
• Requirements gathering is when informal ideas become formal
concepts:
o Converting a concept into something concrete is almost always more
difficult than it is initially believed to be.
o The concept of what the concrete version needs to look like changes
frequently.
Usually more difficult than
thought to be…and usually
changes frequently
The winding road to software
requirements

4
Why are Requirements So Important?
• According to Fred Brooks (the author of The
Mythical Man Month):
• “The hardest single part of building a software
system is deciding precisely what to build. No
other part is as difficult…No other part of the work
so cripples the resulting system if done wrong.”1
• According to Barry Boehm (Software Engineering
Economics) and other software engineering
experts, around 75-80% of all errors found in
software projects can be traced back to the design
and requirements phases.2
1 Brooks, Frederick P., 1987. “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, Volume 20, No. 4.
2 Boehm, W .Barry. “Software Engineering Economics”. Prentice Hall; 1 edition (Oct. 22 1981).

5
The Challenges with Written Requirements
• According to Mike Cohn, author of User Stories Applied:
• “Writing things down is no guarantee that customers will
get what they want; at best they’ll get what they wrote
down.”3
• From Lean Software Development by Mary & Tom
Poppendieck, the Seven Wastes of Software
Development:4
1. Partially Done Work
2. Extra Processes (paperwork)
3. Extra Features
4. Task Switching
5. Waiting
6. Motion
7. Defects
3 Cohn, Michael W., 2004. “User Stories Applied for Agile Software Development”, (Addison-Wesley Professional Series, Boston, MA).
4 Poppendieck, Mary and Poppendieck, Tom, 2003. “Lean Software Development: An Agile Toolkit”, (Addison-Wesley Professional Series, Boston, MA).

6
What is a User Story?
There are numerous definitions for stories.
• A common definition:
o A short description of a function that an
end-user would want.
• From Kent Beck:
o “One thing the customer wants the system
to do…(it) should be testable.”5
• From Ron Jeffries:
o “Stories are promises for…the series of
conversations that will take place between
the customer and the programmers.”6
5 Beck, Kent, 2000. “Extreme Programming: Embrace Change”, (Addison-Wesley, Boston, MA)
6Jeffries, Ron, Anderson, Ann and Hendrickson, Chet, 2001. “Extreme Programming Installed”, (Addison-Wesley, Boston, MA)

7
Why User Stories?
Stories have many advantages.
• Easy to understand
o Written in non-technical language that customers
/ product owners can relate to.
• Work at the right level
o Not too detailed, are easy to manipulate and
move around, like a deck of cards.
• Relatively easy to create
o Writing stories takes some skill, but experts can
define entire systems for planning purposes in a
matter of hours.

8
Story Types
Epic
Feature
User
Story
• Represents multiple features or many stories.
• Can take months to build and works at the release level.
• What the end users tend to focus on.
• Smaller than epics, but bigger than stories.
• Can take weeks, possibly one or more Iterations to build.
• What customers / product owners tend to focus on.
• Are the smallest increment of value.
• Take days, perhaps a week or two at most to build.
• What development teams tend to focus on.
Primary focus of this
presentation.

9
Key Players: Customers & Developers
1. Customers / product owners
o The people who know how to do what the system is
going to be doing.
o They either are the end user or they are
representative of the eventual user of the system.
2. Programmers
o The people who will be building, testing, deploying,
documenting & training those who will use the
system.
Stories are key to fulfilling the requirements in the
Customer and Programmers Bills of Rights.
Cu sto m er Bi l l o f Ri g ht s
• You have the right to an overall plan
• You have the right to change your
mind, to substitute functionality, and to
change priorities
• You have the right to be informed of
schedule changes, in time to choose
how to reduce scope to restore the
original date
Pr o g r am m er Bi l l o f Ri g ht s
• You have the right to know what is
needed, with clear declarations of
priority
• You have the right to make and update
your own estimates

10
User Story Components
At minimum, a user story has:
1. A card to write the story on.
2. A name that the customers and
developers understand.
3. A description (should be limited to
one or two sentences).
4. Acceptance criteria to define when
the story will be considered
completed.
5. A size estimate for time
management.
Pay by Credit Card
As an online customer, allow me to pay by credit card
of my choice so that I can complete my purchase.
Acceptance:
Test payments with VISA, Master Card & Amex.
Reject payments exceeding $1000
Size = 2
A typical story card.

11
User Story Components
Story Name
Description
(no more than 2-3 sentences)
Story Notes
(optional)
Story Priority
(optional)
Story Size
Acceptance
(list of criteria to indicate when
the story will be closed)
Release, Module and ID Fields
(optional - help to identify the story)
Priority Size
2 1
Login
Description:
As an authorized user, provide a login page to gain access to the secure pages of the Web site.
Notes:
 Users to provide IDs and Passwords.
 A ‘Forgot your password?’ link will be needed.
Acceptance:
To be provided by the Customer.
.
ID
SMP-1-2
Client Logo
(optional)

12
Story Actions
Stories can be:
• Split
o A large story can be split into two or more smaller
ones of different sizes; useful for breaking up epics.
• Combined
o Two or more small stories can be combined into one.
• Added
o New stories can be added to an existing backlog.
• Deleted
o Existing stories can be deleted from a backlog.
+
X

13
The 3 Cs of Stories
•Card
o A token to represent some customer functionality.
o Stories represent customer requirements rather than document
them.
o Using a card keeps the story short.
•Conversation
o Customers and developers discuss the details of the story at the
time it is to be developed, not before then.
•Confirmation
o The customer should provide acceptance tests for the story, and
then see them run to confirm that the story has been completed.

14
User Roles and Description Formats
• Identifying user roles helps with writing stories.
• Standard story description template:
As a [role], provide [function] so that [business value].
• Some simple examples:
o As a customer, provide a button that I can use so that I can
connect directly with the call centre when my order gets stuck.
o As a call centre rep., review orders in progress online so that I can
help customers complete their orders.
o As a manager, access stats on incomplete online orders so that I
can make decisions on how to improve the ordering process.
Call Centre Rep.
Manager
Customer

15
Writing Stories – The INVEST Framework7
•Testable – It must be possible for the development team to write tests for the
story.
•Small – Stories that are too big are not useful in planning.
•Estimatable – Stories should be understood well enough by customers and
should be small enough to be “estimatable”.
•Valuable – The feature should have business value to the customer.
•Negotiable – Stories should be written so that the details can be negotiated in
a conversation between the customer and the development team.
• Independent – Dependencies between stories should be avoided.
7Wake, Bill. “INVEST in Good Stories, and SMART Tasks”. Posted August 17, 2003 on XP123.

16
User Stories vs. Use Cases
• A story can be considered similar to a lightweight use case.
o A story can represent a small piece of a use case.
• Use cases cut across many functions and may touch on many stories.
© 2014 Intelliware Development Inc. Functions
Technologies
Story
Use case

17
Examples of Common Story Mistakes
Not testable!
Not
functional.

18
Too big…should
probably be split as
follows:
1. Pay by one credit
card (including
payment
infrastructure)
2. Pay by additional
credit cards

19
This is huge, with
many functions;
an epic!
Also, there’s
more than one
user type.

20
This is not
independent as
there is a
dependency on the
List Flights Story.
Should be split
along another
dimension.

21
For More Information
Mike Cohn’s site contains a good section on
user stories:
http://www.mountaingoatsoftware.com/agile/user-stories
The Agile Alliance site is also a good
resource:
http://guide.agilealliance.org/guide/user-stories.html
Intelliware’s Knowledge Centre contains
several resources on the basics of Agile:
http://www.intelliware.com/knowledge-centre

23© 2014 Intelliware Development Inc.
About Intelliware Development Inc.
Intelliware is a custom software, mobile solutions and product development
company headquartered in Toronto, Canada. Intelliware is a leader in Agile
software development practices which ensure the delivery of timely high quality
solutions for clients. Intelliware is engaged as a technical partner by a wide
range of national and global organizations in sectors that span Financial
Services, Healthcare, ICT, Retail, Manufacturing and Government.
/company/intelliware-development-inc-
/intelliware.inc
/intelliware_inc
/GooglePlusIntelliware
www.intelliware.com

Agile Story Writing

In this document