The document discusses the characteristics of effective user stories according to the INVEST principles. User stories should be independent, negotiable, valuable, estimable, small, and testable. They are written on index cards or electronically as placeholders for further discussion to flesh out requirements, and include who wants what functionality and why to help prioritize stories.

1. Identify Effective User
Stories

2. 3 C’s of a User Story
Card
Characteristics
of a User Story
Confirmati Conversatio
on n

3. Card
User stories are written on Cards
It‟s used as a token for planning, analysis and tracking
What a Story Card IS:
It‟s a placeholder which contains just enough text to identify the
requirement and to remind everyone what the story is.
What a Story Card IS NOT:
It‟s not a requirement document which contains all the information
which makes up the requirement.
Tools such as Mingle can be used to record these electronically and to
track them on a shared environment.

4. Conversation
A story is a placeholder for a Conversation
and not a written contract.
Customer communicates requirements to the Analyst
This is largely Verbal and takes place over a period of time.
These are all captured in documents called „Story Narratives‟
Face-to-face discussions are valuable, but as we get closer to an
Iteration, these discussions, implementation details get committed on
these narratives.

5. Confirmation
Although a Story Card is a placeholder for discussion, we still need to know
what we want to achieve with a story i.e. what the customer would want to
see in order to sign-off the story.
These are captured in Acceptance Criteria in the story
These Acceptance Criteria are narrowed down through conversations with
the customer.
The developers then complete the story using the Acceptance Criteria as
guidance.

6. Role, Process, Goal
Stories are written in Simple Business language and are
represented in the Role, Process, Goal format.
Role
Process
Goal

7. Role
The Role in a User Story defines who wants this
requirement to be fulfilled. We mention this so that we
speak to the right people and understand the story
better.
Role
The Role is indicated by
“As an administrator….” OR
Process “As a Banker….”
Goal
As an Internet
Shopper….

8. Process
The Process part of the story indicates what the “Role”
would like to do. This is basically the set of steps they
would like to perform.
Role
Example:
As an Administrator,
I want to see who is logged onto the system… ”
Process
Goal
I want to shop using my
iPhone….

9. Goal
The „Goal‟ indicates the business value the user will get
from the „Process‟.
It‟s important to collect this information since it helps the
customer prioritize this story against others depending on
Role
the value gained.
Example:
Process As a customer
I want to withdraw money from the ATM
So that I can shop using cash
Goal
So that I can order my
package anytime, from
anywhere

10. Characteristics of a Good Story (INVEST)
Independe
nt
Negotia
Testable
ble
INVEST
Principle
Valuabl
Small
e
Estimabl
e

11. Characteristics of Good Stories
Independent
A user story should be as independent of other stories as possible.
It should be able to be developed on it's own
Avoids dependencies on other cards
We can reduce dependencies by either combining stories or splitting the stories
differently.
Stories which are not independent makes planning, prioritization and
estimation much more difficult.
Negotiable
A user story is negotiable; It's not a written contract.
A good story captures the essence of what's needed but doesn‟t include details.
Details are worked on during the Conversation phase.
Cards with too much detail limits conversation with the customer.

12. Characteristics of Good Stories…
Valuable
When possible, stories should be vertical slices of real functionality (think of
slicing a cake - you want all the layers, but a thin enough slice so you can eat it
all)
Valuable to the role (actor) (As an X)
Valuable to the business (I want to Y)
Has clear and valid business value (So I can Z)
Estimable
Stories are elements of planning and must be estimable
If we can‟t estimate a story then it might be too large OR developers might need
more domain/technical knowledge to understand it.

13. Characteristics of Good Stories…
Small
Large stories are hard to estimate and hence to plan
They often hide big ticket work
Should fit within one iteration
Testable
Stories should be testable. If you can‟t, then you will not know when you are
done.
They should be testable through the UI