Writing Effective User

Stories
The Scrum Rituals
STOCKING
BACKLOG
O PO develops in collaboration with
stakeholders
O Product Roadmap may drive themes & epics
O Items at top fit into a sprint
O Whole backlog indicates direction
O 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 –  Daily, 15-minute synch-up
O –  Same time, same place
O –  Stand-up, no problem solving

• Answer the 3 questions:

O –  What did you do yesterday?
O –  What do you commit to do today?
O –  Are you blocked?

• Impediments = SM’s Task List

• Note the Decisions
• Stakeholders are invited to observe but can’t
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.
What’s 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 It’s 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, it’s 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 DON’T HAVE TO RELY ON MY LAZY BOSS
ANYMORE.
Let’s 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 dog’s online food order portal

Here we are switching the view from the developer to the end user.
So you put yourself in the end user’s 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 Unit test
O code review
O 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
What’s 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 don’t 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 don’t yet
know, we are worried about?
1, 2 , 3 , 5 , 8 , 13 ,

20 , 40 , 100
Population / Size / Per Capita income

COUNTRY POINTS
Country Points
Finland
Denmark
USA
China
Austria
Canada
Brazil
France
India
Germany
Slovakia
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 Pick next card and place it relative to the first based on
O size/complexity. Explain.
O For each move thereafter,
o Pick the next card and place it,
o Move a card that’s already been placed, or
o Pass.
o Explain your move and let the team discuss.
O Continue until there are no more moves to be made.
O Collect into stacks if not already stacked.
O Assign points to each stack.
Created by:
Steve Bockman
Bucketed Relative Sizing

S L
1 3 5 8 13