Become familiar with the User Story approach to formulating Product Backlog Items and how it can be implemented to improve the value and quality of the product by facilitating a user-centric approach to development

1. Agile - User Stories

2. Objectives
2
Become familiar with the “User Story” approach to
formulating Product Backlog Items (PBIs) and
how it can be implemented to improve the
communication of user value and the
overall quality of the product by facilitating
a user-centric approach to development.

3. Introduction to User Stories
3

4. “User Stories tell a product
narrative so everyone
understands the essence of
what they are building, and the
benefit it provides.”
4

5. 5
● Increases collaboration between team
members.
● Aids in creating baseline of knowledge
and expectations across the team.
● Are simple, concise, just-in-time.
● Clearly indicate the value provided.
● Simplifies planning.
● Enable real-time feedback
● Minimal Viable Product concept.
USER STORIES TRADITIONAL REQUIREMENTS
● Limits collaboration and innovation.
● Limits communications and shared
knowledge.
● Are heavy, complex and may be
outdated once completed.
● Value often unclear or unstated.
● Complex planning
● Disables real-time feedback
● All or nothing concept
User Stories vs Traditional Requirements

6. Crafting Quality User Stories
6
Characteristics of a well-formed user story:
● I – Independent
● N – Negotiable
● V – Valuable
● E – Estimable
● S – Small
● T – Testable

7. Independent
Stories are easiest to work with if they are Independent.
That is, we are able to schedule and implement them
in any order.
● It allows for true prioritization of each and every story.
● When dependencies come into play it may not be possible
to implement a high value story without implementing
other much less valuable stories
7

8. Negotiable
A good story is Negotiable. It is not an explicit contract for
features; rather, details will be co-created through
collaboration.
● A good story captures the essence of what is desired, it is
an invitation to a conversation.
● The actual result needs to be the result of collaborative
negotiation between customer and the team.
● The goal is to meet customer needs, not develop
something to the letter of the user story - if doing so is
insufficient or negatively impacts other users.
8

9. Valuable
Each story offers clear value or benefit to either end users
(outside the development team), or to the team itself, or to a
stakeholder.
● The business value of the story, the “why”, should be
clearly understood by all.
● All stories should be connected to clear business goals.
This does not mean that a single user story needs to be a
marketable feature on its own.
● The completion of a User Story should always result in
added value for the user. The definition of “user” can be
broad in this sense, and it may not always be a consumer
end-user.9

10. Estimable
● The team should understand the story well enough to be
able estimate the complexity of the work and the effort
required to deliver the story.
● This does not mean that the team needs to understand all
the fine details of implementation in order to estimate the
user story.
● Is the Story too complex, too big? In this case, simply
break it down into multiple User Stories, until it is more
reasonable to estimate and can be completed in a sprint.
1
0

11. Small
● Can also be thought of as level of effort.
● The item should be small enough that the team can
deliver a potentially shippable increment of functionality
within a single Sprint.
● As the product backlog is refined, stories may be split to
ensure they may be completed in the given time.
● When stories are too big they can be split, some ways of
splitting stories includes; split by workflow, role, data.
1
1

12. Testable
● Each story specification is clear enough to be able to
develop all test cases from its acceptance criteria.
● Everyone should understand and agree on how the
completion of the story will be verified, the definition of
“done” is one way of establishing this.
● If everyone agrees that the story can be implemented in a
way that satisfies the current definition of “done” in a
single Sprint and this definition of “done” includes some
kind of user acceptance test, then the story can be
considered testable.
1
2

13. The Three C’s of a User Story
A User Story has three primary components, each of which
begin with the letter “C”:
1
3
Conversation
Confirmation
Card A brief statement from the perspective of the
user , that can fit on a card
An invitation to a conversation, promoting
collaboration.
Acceptance Criteria provides the conditions
the product must satisfy to be accepted.

14. The Card
● The Card, or written text of the User Story is best understood as an
invitation to a conversation.
● This key concept fosters the understanding that in Scrum, you don’t
have to have all of the Product Backlog Items written out perfectly “up
front”, before you bring them to the team.
● It acknowledges that the customer and the team will be discovering
the underlying business/system needed as they are working on it.
● This discovery occurs through conversation and collaboration around
user stories.
● The user story follows a specified format.
1
4

15. User Story Format
1
5

16. 1
6
Let’s Try It!
Write a User Story

17. The Conversation
● An opportunity to elaborate on the details captured at the
previous stage. In some planning meetings this will
happen as the card is being written.
● The collaborative conversation, which involves all
stakeholders and the team.
● The conversation is where the real value of the story lies
and the User Story is adjusted to reflect the current
shared understanding of this conversation.
● The conversation is largely verbal, but can be
supplemented if necessary with simple examples (white
board sessions, simple mockups, etc)1
7

18. 1
8
Let’s Try It!
Have the Conversation

19. The Confirmation
● To ensure the user story has been implemented in the
desired form, acceptance criteria are defined.
● Acceptance Criteria are the conditions that the software
must satisfy to be accepted.
● Prior to the start of the implementation of a story, the
customer defines the central criteria for the acceptance of
the story later.
● By testing against the conditions the team can confirm
that the story is complete before it can be considered
“done”
1
9

20. More on Acceptance Criteria
2
0
Acceptance Criteria are a set of statements,
each with a clear pass/fail result.
They represent “conditions of satisfaction.”
They add certainty to what the team is
building.

21. 2
1
Let’s Try It!
Define the Acceptance Criteria

22. 2
2
Quiz Time!