Writing Effective User

Stories

The Scrum Rituals

STOCKING
BACKLOG
O PO develops in collaboration with
O
O
O
O

stakeholders
Product Roadmap may drive themes & epics
Items at top fit into a sprint
Whole backlog indicates direction
Never done, evolves over time

GROOMING
BACKLOG
Whole-team collaboration
Right-size items
Define major acceptance criteria
Assign size
Always on-going and evolving

The Daily Scrum/Standup

Rules:
O
O
O

Daily, 15-minute synch-up

Same time, same place
Stand-up, no problem solving

Answer the 3 questions:

O
O
O

What did you do yesterday?

What do you commit to do today?
Are you blocked?

Impediments = SMs Task List

Note the Decisions
Stakeholders are invited to observe but cant

talk:
O

Take issues to ScrumMaster/Manager after the Standup has ended

First things first

O

Scrum Master facilitates

O Prioritize the features Product Owner /
Business Owner along with the technical lead
O User Stories Technical Lead along with the
team
There are several ways to prioritize the requirements in
the backlog. Some of the most popular ones include,
MoSCoW
O M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything
else.
W - WON'T have this time but would like in the
future.
Each requirement will have the priority which would be
tagged to MSCW. M being the highest and W being
the lowest.

Whats a User Story?

So what really is a User Story?

O User stories are very slim and high-level

requirements artifacts
O User stories are oriented to reflect the desires

of the end user, they help developers remain

focused on the customer.

User Story Vs Spec Doc

User stories offer a quick way of handling customer requirements without having
to create formalized requirement documents and without performing
administrative tasks related to maintaining them. A project will gather user stories
in order to respond faster and with less overhead to rapidly changing real-world
requirements. Flexibility & Satisfaction.

INVESTing in a Good Story

INVESTing in a Good Story

The INVEST criteria are Independent, Negotiable, Valuable, Estimatable, Small
(sized appropriately), and Testable
Independent
O As much as is practical, user stories should be independent or at least only
loosely coupled with one another.
Negotiable
O Stories are not a written contract. they leave room for the product owner, the
stakeholders, and the team to negotiate the details
Valuable (Serve a purpose)
O Stories need to be valuable to a customer, user, or both. Technical Stories can
exist, provided it delivers value ultimately
Estimatable & Small (Achievable)
O Its hard, if not impossible, to plan sprints around stories that are too big
Testable (Specific)
O Without a clear idea of how to prove the doneness of a story, its almost
guaranteed that the PO and the Scrum Team will not be seeing the story in the
same light.

What is in a User Story?

written description or short title of the story
used as a token for planning and as a reminder
to have conversations
conversations about the story that serve to
flesh out the details of the story
acceptance tests that convey and
document details and that can be used
to determine when a story is complete

AS A <type of user>,
I WANT TO <goal>,
SO THAT <reason>.

AS A DOG,
I WANT TO BE ABLE TO ORDER FOOD ONLINE,
SO THAT I DONT HAVE TO RELY ON MY LAZY BOSS
ANYMORE.

Lets Dive Deep

Technical - Who ? Developer & Tester
Clearly articulate the requirement in the below format
As a user (end user)
I want to do xxxxxx (how to do this when this can be done in several diff. ways)
So that I can xxxx (end result achieved) (context)
Example : The dogs online food order portal
Here we are switching the view from the developer to the end user.
So you put yourself in the end users position. Setting the context so that as a team
we can see the bigger picture. In waterfall model people think which piece I have to
deliver.
Ordering online Generic
But who is ordering the game changer

Epic & Theme

User story Abstraction

Hierarchy

WHERE ARE THE DETAILS?

Conditions of satisfaction defined

Details added in smaller sub stories

Acceptance Criteria - Quantitative and

Specific
Why?
Behavior Driven Development (BDD) write minimum code that is required to successfully
complete a feature.
Every line of an acceptance Criteria (business case) should be tested
O Testers will write test cases based on the AC
O Business Criteria
AN Acceptance Criteria
O defines the boundaries for a user story/feature
O help the product owner answer what she needs in order for this feature to provide value
(typically these are the minimum functional requirements)
O help the team gain a shared understanding of the story/feature
O help developers and testers to derive tests
O help developers know when to stop adding more functionality to a story

Now that the minimum code has passed does it mean that we are done?

Definition of Done
O This is where DOD comes into place Code

should be maintainable, manageable and

follows a standard and to reduce the Cost of
quality
O Size of a story = effort to work a story to DONE
DONE
O Need absolute clarity and agreement
O The more you put into the sprint, the less risk
when you get closer to the release

Sample Definition of Done

Definition of Done for a Story
Working software + demo
O
O
O

Unit test
code review
Installer

Tests -> testcase + proof of successful run

Functional run
Functional review by product owner
Performance or load testing
Regression tests
Documentation + review by PM/MA
User docs / online help
Design doc (intern use)
Samples for critical features
Release notes
API documentation

Whats the Risk?

O The user story should have all the information that will be needed

to consider the story as complete, without which progress cant be

tracked.
O MVP minimum viable product it is essential that the User story

breakdown gives a clear understanding of the amount/type of work

that is needed and whether it is achievable and whether it will have
an impact on the PSI eventually
O RISK- when the above exercise is not completed effectively, there is

a high chance of identifying critical issues at a point where things

go out of hand and potentially can jeopardize the goal of the
project.

Icebox
O All the Features that dont have user stories /

AC / DOD are isolated and stored for future

Its an imaginary line that we draw to say that
the items below this is not clear and needs to be
broken down

Backlog
sizing

we are not good at

estimating

we are good at

comparison

Start with a rough size . . .

. . . then get more specific

What Sizing Considers . . .

O Design technology other considerations
O Code Complexity / Business logic / have

been done before?

O Test Manual / Automate / Test
O And???

What Sizing Considers

Complexity
How many moving parts are involved in delivering
This?
Effort
How much effort will it take to get it done?
Doubt
Are there things about this that because we dont yet
know, we are worried about?

1, 2 , 3 , 5 , 8 , 13 ,

20 , 40 , 100

Population / Size / Per Capita income

COUNTRY POINTS
Country
Finland
Denmark
USA
China
Austria
Canada

Brazil
France
India
Germany
Slovakia

Points

Sizing Estimating

PLANNING POKER

PLANNING POKER
O Read user story, discuss briefly
O Each team member selects estimate card

O Cards all turned over at once

O Discuss difference and outliers
O Re-estimate until estimates converge

Bucketed Relative Sizing

Team Estimation Game

(aka Bucketing)
O Place a story card on the table
O

O
O

O
O
O

Pick next card and place it relative to the first based on

size/complexity. Explain.
For each move thereafter,
o Pick the next card and place it,
o Move a card thats already been placed, or
o Pass.
o Explain your move and let the team discuss.
Continue until there are no more moves to be made.
Collect into stacks if not already stacked.
Assign points to each stack.
Created by:
Steve Bockman

Bucketed Relative Sizing

S
1

L
13