You are on page 1of 17

Backlog, User stories, Acceptance

Criteria, Definition of Done

Irina Stanila, 26 June 2014

INVEST

Ready user
story

Users
proxies

User
stories

Definition
of done

Product
backlog

Acceptance
criteria

Good user
stories

What is a user story?


Functionalities that are valued by users.
They should be written as user value them.
The 3 Cs

A user can post


an article to the
blog.

Card: written on a card

Conversation: Details are captures in conversations

Confirmation: Acceptance criteria confirm that a story is


done

Is the title of the


article compulsory?

Will the editor have


a spell checking?

Article title is compulsory.


Editor should not be with
spell checking
Date of posting will be
taken automatically from
the phone settings.

Who writes the user stories?


-

PO accountable for the Product backlog, for the


business value of the user stories

User stories can be a team effort, where product


owner and the team create the stories together.

Important to have QA and the Interaction


designer when defining the user stories so that
they come with the User perspective

INVEST
Independent
- Avoid introducing dependencies between stories. If stories are not independent
problems can occur at prioritization and estimation

egotiable
Details of stories are negotiable between customer and development team.

Vaaluable to purchasers or users


The best way is to have the customer write the stories.

INVEST
E stimable
Developers should be able to estimate a user story.

mall
Size should be appropriate in order to plan them

estable
Whenever possible tests should be automated.

Users proxies
Users manager
- not a typical user, less frequent used features could be
overemphasized.
A development manager
- Worst possible choice unless the software is targeted to
development managers
Sales persons
- Very helpful if they have contact with a variety of users but
they avoid features with which they dont make sales
Domain Experts
- Good when building a domain model and identifying
business values
- Potential problem: software aimed only at user with
similar level of domain expertise

Proxy

Users proxies
Marketing group
o Experience with markets rather than users.
o Quantity of features vs quality of features
Former user
o If the experience is recent can be a great proxy
Trainer and Technical support
o Training easy and supportability good goals but
most likely not what a true user would prioritize
Business and system analysts
Good choices

Proxy

Working with user proxies


Users exists but access is limited
o Work with proxy but also establish a connection to
hands on users.
o PO remains the final decision maker
When really there is no user available
o Use more than one user proxy.
Different types eg. Domain expert and someone from
marketing
o Release the product as soon as possible

A real user beats a proxy any time!

Acceptance criteria
Scope behind the user story
It is what the product owner wants to see
implemented
Also known as How to demo

Responsible for writing the acceptance criteria: the


customer

Guide to good user stories

Vertical user stories

Guide to good user stories


Write Constraint cards

Keep stories short

Write smaller stories for functionality that soon


will be implemented and broader stories for
functionality further out

Product Backlog

Different items:
Product vision new features
Technical requirements
Security and performance requirements

Improvements
Requirements that elicit after the
retrospective

Bugs (if a bug takes as much work as a


story)
Bugs that are solved quickly combine in
1 or 2 stories
Constraints not estimable

Owned by product owner

Sprint backlog
Product backlog
User story 1
User story 2

Sprint backlog

User story 3

Owned by the team

User story 4
User story 5
User story 6

User story 7

When is a user story ready for


development

criteria
clear
feasible and
testable

Done in backlog refinement


activity

Definition of Done
Should be broad enough to cover
potentially shippable functionality/ all
product backlog items.
Not at for each user story
Should be defined by the team and PO

Great product

You might also like