user stories
DESCRIPTION
Traditionally, building the right product required big functional specifications, documentation, and long testing phases. Nowadays teams write just enough documentation to facilitate change effectively in short iterations or in flow-based development.TRANSCRIPT
Backlog, User stories, Acceptance Criteria, Definition of Done
Irina Stanila, 26 June 2014
User stories
INVEST
Users’ proxies
Acceptance criteria
Good user stories
Product backlog
Definition of done
Ready user story
What is a user story?
• Functionalities that are valued by users.
• They should be written as user value them.
• The 3 C’s – Card: written on a card
– Conversation: Details are captures in conversations
– Confirmation: Acceptance criteria confirm that a story is done
A user can post an article to the blog.
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
egotiableDetails 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 stimableDevelopers should be able to estimate a user story.
mall Size should be appropriate in order to plan them
estableWhenever 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 don’t 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 backlogUser story 1
User story 2
User story 3
User story 4
User story 5
User story 6
User story 7
Sprint backlog
• Owned by the team
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