User Story Writing & Estimation For Testers By Mahesh Varadharajan

User Story Writing and
Estimation for Testers
Mahesh Varadharajan
Agile Consultant
Confidential | Copyright © Agile Testing Alliance Global Gathering

Introduction
The real challenge in writing software isn’t
the time spent writing the code itself.
Instead it’s the time spent deciding what
software we should build, and perhaps just
as importantly what we shouldn’t build.

Traditional development
Boehm’s Cost of Change Curve: Change gets more expensive over time

The Agile Solution
Transition from Big Requirements Upfront
(BRUF) to Just-in-time (JIT) elaboration
User Stories are an Agile approach to
solving this problem; they’re lightweight,
simple requirements.

Definition
User stories are short, simple description of a feature told from the
perspective of the person who desires the new capability, usually a user or
customer of the system.
Use simple English to write a user story
There are several ways of writing a user story, templates help to build
consistency

The Cohn’s Format
“As a [type of user] I [want/can/am able
to/need to/etc.] so that [some reason]”
• Who: Role
• What: Context / Want
• Why: Benefit

3C’s: Components of a User Story

How User Stories Evolve?

INVEST on User Stories

Is your Acceptance Criteria SMART?
Specific
Measurable
Achievable
Relevant
Time boxed

Testability of User Stories
Stories must be written so as to
be testable, with conditions of
satisfaction
Successfully passing its tests
proves that a story has been
successfully developed, agility
relies upon feedback loops
Testability
If the story cannot be tested,
how can the developers know
when they have finished
coding?
Untestable stories commonly
show up for NFRs, which are
requirements about the
software but not directly about
its functionality.

How will you test these stories?
A user must never have to wait long for any screen to appear
A novice user is able to complete common workflows without training
A user never has to wait long for any screen to appear
As a user, I want to calculate the cost of repairing a crashed car
As a user, I want the system to be fast
As a user, I want the system to be secure
As a user, I want the system to be easy to use

Story Writing Workshop
Exercise-1: Story Creation
Duration: 10 minutes

Rules of the Game
• Form teams of about 7 +/-2 members
• Choose your own product or select one per
team from the list given below.
• Each team member to create at least three
user stories without any discussion with each
other
• Railway ticket booking wallet on Mobile
• E-Commerce Portal like Flipkart or Amazon on
Mobile
• Mobile Money
• Mission Critical Embedded Software System to
control trucks and heavy machineries

Exercise – 2
Develop Stories for your Persona

Identify Persona
• For the chosen product in Exercise-1,
identify the persona or possible roles who
will interact with the system, as a team.
• Each team member to choose your own
persona from the identified list and
create user stories for your persona
without any discussions with the team
members

Exercise – 3
Story Writing for Personas
as a team

Create Stories for the Persona
1. Choose a Persona
2. Write AS A <<your persona>> pass it on to
the person on your right.
3. Write I WANT <<for the persona you have
got>> pass on to the person on right.
4. Write SO THAT and keep in at the center
of your table.
• Repeat steps 1-4 until you have covered
all the personas, steps 2-4 should be
written by different person every time

Share your Learnings
Discussions

Inference
• Writing user stories is not so easy
• There may be duplicates
• Thinking of personas first, really helps
• Each persona might look at the same
feature differently
• Each persona would want different
features
• Each persona has its own priority for
features

Common Pitfalls in Writing Stories
User Story for a
Generic or Unknown User
User Story for
Product Owner than end
user
User Story for a technical
layer like DB, developer
oriented
No Business Value or
Benefit for Customer
No Acceptance Criteria or
Conditions of Satisfaction
Story is Vague or
ambiguous.

Recommendations
Identify the Persona or Roles to give clues about user
expectations
Avoid generic users as it may lead to conflicting multiple
user expectations from the same user story, lacks specific
Avoid the approach of “you want a story, here you have
one”
Technical requirements or debt should not lead to writing
stories for developers

What about NFRs?
• Non Functional Requirements (NFRs)
• i. Dedicated to a user story
• Mention it in acceptance criteria
ii. Relates to multiple user stories
• Create a separate user story

User Story Estimation

Are your Stories Estimatable?
• Three common reasons why a story may
not be estimatable:
• Developers lack domain knowledge.
• Developers lack technical knowledge.
• The story is too big.
• Solutions: Split Story
• Split on vertical basis. Not on horizontal
layers.
• Spike in case story needs to be investigated
for want of details, a spike story may be
scheduled.

Techniques for Estimation
• Wideband Delphi and Planning Poker
• Ideal Time
• Relative Sizing / Story Points
• Affinity Estimation

Affinity Estimation - Introduction
• Let’s say You have just finished to create
the user stories for your product and, a
bit proudly, your product backlog now
counts two or three hundred of items.
How can you estimate them, effectively?
• How can you give a quick rough
estimation of the product backlog, in 3 to
4 hours?
• Group similar sized stories together

Characteristics of Affinity Estimation
• Quick and Easy
• Make decision fairly transparent and
visible
• Create a positive and collaborative
experience rather than confrontational
exercise in estimation session.
• Whole team participates – Product owner,
Scrum Master and Iteration Team

Affinity Estimation > Steps
Silent Relative Sizing
Edit the Wall
Place items into relative sizing buckets
Product Owner Challenge
Store the data

Affinity Estimation

Illustration: Affinity Estimation Steps

Exercise – 4
Affinity Estimation

Affinity Estimation
To Find:
1) What is the total size and expected duration of the project?
2) How many iterations will it take to deliver?
3) Estimate the Product Backlog items that were identified for various
personas using affinity estimation
Steps:
• Each person in the team gets a turn to estimate a new card or move an
existing card silently, using relativity of SMALL Vs BIG
• Repeat this until you are done estimating all your stories
• On top of the left most card post a card with 1 written on it
• Next from the left, write 2, then 3, 5, 8, 13, 20, 40, 100.
• Write the estimate on each story card now.
• Add up points on each story card and thats the size of the entire project.
• Discuss how much your team can deliver in one sprint.
• Total size / how much we can do in 1 sprint = number of iterations
required for the project

Thank You
in.linkedin.com/in/maheshvaradharajan
@mahesh_mkr

User Story Writing & Estimation For Testers By Mahesh Varadharajan

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to User Story Writing & Estimation For Testers By Mahesh Varadharajan

Similar to User Story Writing & Estimation For Testers By Mahesh Varadharajan (20)

More from Agile Testing Alliance

More from Agile Testing Alliance (20)

Recently uploaded

Recently uploaded (20)

User Story Writing & Estimation For Testers By Mahesh Varadharajan