Through the webinar, she will give an introduction to the user story concept. How to create them? How they can help us build better products for our customers. Do's and Don'ts.

1. The whole story of
the user story
13 Oct. 2021

2. Presented By &
Session Title
XP Days xpdays.org is an initiative
for gathering people interested in
Agile, eXtreme Programming (aka:
XP), Scrum, Coding, etc.
XP is a lightweight, efficient, and low-
risk Agile Software Development
Framework intended to improve
software quality.
Agile Arena agilearena.net is an Agile
Consulting and Training company. specialized in
agile adoption and transformation for companies
and teams through:
• Designing their agile adoption programs
• Executing our programs and guiding the team
through their journey to sustainable agility .
• We also provide accredited training classes
for companies and individuals

3. This Webinar
is Held By:
Aneta Adamczyk
Scrum Master
AT&T

4. Presented By &
AGENDA
1. Introduction
2. Why user stories
3. User Story Template
4. Writing user stories
The whole story of the user story
What we’ll be covering this webinar

5. Presented By &
Session Title
A user story is an informal, general explanation
of a software feature written from the
perspective of the end user or customer.
What is a user story?
What is a user story and where does it come from?
In 1999: Kent Beck published the first edition of the
book Extreme Programming Explained,
introducing Extreme Programming (XP) and the usage of
user stories in the planning game.*)
*) wikipedia.org
Fun fact
Scrum Guide does not mention user
story at all. It tells us about Product
Backlog item

6. Presented By &
Session Title
What user story is really for?
User Story is only meant to describe a
feature, but not describe how to implement
it, meaning leaving out the technical aspect,
it should describe the behavior or flow from
user’s perspective.
A user story is basically a use case. What do
your users need the software to actually
do?
A story should be a unit of work that a team
commits to in an iteration. Whether or not
that unit requires further break down (e.g.
subtasks) should be up to the team.

7. Presented By &
Session Title
What problems do stories address??
• Software requirements is a
communication problem
• Those who want the software must
communicate with those who will build
it

8. Presented By &
Session Title
Balance is critical
If either side dominates, the business loses
• If the business side dominates…
… functionality and dates are mandated
with little regard for reality or whether the
developers understand the requirements
• If the developers dominate…
… technical jargon replaces the language of
the business and developers lose the
opportunity to learn from listening

9. Presented By &
Session Title
So what do we do?
We make decisions based on the
information we have
… but do it often
This is where user stories
come in

10. Presented By &
Why user stories?
Session Title

11. Presented By &
Session Title
User story format
User story describes both the requirement and the value to the stakeholder
The concept of writing a user story is to start a conversation around the story, and the mutual understanding that
we try to build, the value we want to offer to a user and how the user will utilize it.
A user story answers 3 important questions:
1. Who are you building this for?
2. What are you building?
3. Why are you building this?

12. Presented By &
Session Title
• The agile recommendation is
to break down a set of user
stories into smaller ones,
containable into a single sprint
duration, or ideally, a user story
shouldn’t last more than a
sprint
Characteristics of a User Story – INVEST acronym
Independent
Negotiable
Valuable
Estimable
Small
Testable
A User Story should be self-
contained, in a way that there is no
inherent dependency on another User
Story
User Story is not explicit contract, it
IS an invitation to the conversation
A User Story must deliver value to the
business. Period.
You must always be able to estimate
the size of a User Story
User Story should not be so big as to
become impossible to
plan/task/prioritize with a certain level
of confidence
A User Story must provide the
necessary information / evidence
when completed.

13. Presented By &
User story template
Session Title

14. Presented By &
Session Title
3 Cs
The Card
The high level description of the desired system behaviour
The Confirmation
Acceptance Criteria confirm a story was delivered correctly
The Conversation
Details behind the story come out during conversations with Product Owner

15. Presented By &
Session Title
User Story – The Card
1
5
User Story # …..
As a <who> ……………………………………
I want <what> …………………………………
So that <why> …………………..…………….
Acceptance Criteria:
Given <some context>
When <some action is carried out>
Then <a set of observable outcome should occur>
Priority: .......... Size: …….
There is no specific format for defining a user story in agile.
No template for a user story is enforced by any agile methodology
It only outlines the minimum information to be collected at the beginning
Front card Back card

16. Presented By &
Session Title
User Story – The Conversation
1
6
• Discuss your ideas with others
• Let them ask lots of questions
• Work together to come up with ideal solutions
The goal is to build
a shared understanding

17. Presented By &
Session Title
User Story – The Confirmation
1
7
Acceptance criteria
is a formalized list of requirements which ensures a
story has been completed and all scenarios are taken
into account.
• Put simply, acceptance criteria specify conditions
under which a user story is fulfilled.
• Concisely written criteria help development teams
avoid ambiguity about a client’s demands and
• prevent miscommunication.
• Clearly written criteria introduce a single solution
to the functionality you intend to implement.

18. Presented By &
Session Title
User Story – The Confirmation
1
8
Acceptance Criteria - short cheat sheet
1. Write Acceptance Criteria in “client” language.
2. Keep Acceptance Criteria technology agnostic as much as possible.
3. Avoid keywords such as all, any, every, if appropriate, etc.
4. Describe any follow-on actions during or after the user performs the activity
5. Don’t try to cover everything! Focus only on those things that are of value to the client.
6. Less is more!

19. Presented By &
Writing user stories
Session Title

20. Presented By &
Session Title
Why you should write a user story?
As a Product Owner (PO) when you receive a user story from any source you should be asking yourself
following questions:
• Why are we doing this, what is the business or technological gain?
• What is it for, who will be the user actually using it?
• Remember the 80/20 rule - if you are spending too much effort on providing the feature which is either
not requested by many users, or doesn’t add much value.
• What value does it drive, what is the priority?
• How does it fit our portfolio?
• What’s your estimates on time to implement?
• What skillset do you need?
• What are the acceptance criteria or CoS (condition of satisfactions)?
• What testing will be needed?
Product owner and the team should decide on what they feel is the most appropriate way to describe the
work that needs to be done. As team know how part and PO knows the what part

21. Presented By &
Session Title
The Product Backlog Iceberg
Priority
Sprint / Iteration
Release
Future Release

22. Presented By &
Session Title
5 most common mistakes
• User Story for a User
Example: "As a user I want to be able to manage ads, so that I can remove
expired and erroneous ads."
1.
Who is the
user??

23. Presented By &
Session Title
5 most common mistakes
• User Story for Product Owner
Example: "As a Product Owner I want the system to have possibility of
deleting ads, so that users have possibility of deleting ads."
2.
“you want story,
here you have
one”
Who is the user??

24. Presented By &
Session Title
5 most common mistakes
• User Story for Developer
Example: "As a developer I want to replace the folder widget, so that I have
maintained folder widget."
3. Where is the
value to the
customer?

25. Presented By &
Session Title
5 most common mistakes
• No Business Value or Benefit for Customer
Example: "As an commercial advertiser I want to have filtering option.”
4.
Where is the
value to the
customer?

26. Presented By &
Session Title
5 most common mistakes
• No Acceptance Criteria or Conditions of Satisfaction
Example: "As a commercial advertiser I want to have filtering option.” (example from
above)
5.
What are
conditions of
satisfaction?

27. Presented By &
Session Title
Don’t forget
Don’t forget the purpose
The story text we write is less important than
the conversations we have with the customer
and within the team

28. Presented By &
www.agilearena.net
www.xpdays.org
Session Title

29. Presented By &
DISCUSSION
Session Title
OPEN DISUCSSION