User Stories
-
Upload
irina-stanila -
Category
Documents
-
view
8 -
download
0
description
Transcript of User Stories
![Page 1: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/1.jpg)
Backlog, User stories, Acceptance Criteria, Definition of Done
Irina Stanila, 26 June 2014
![Page 2: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/2.jpg)
User stories
INVEST
Users’ proxies
Acceptance criteria
Good user stories
Product backlog
Definition of done
Ready user story
![Page 3: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/3.jpg)
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.
![Page 4: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/4.jpg)
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
![Page 5: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/5.jpg)
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.
![Page 6: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/6.jpg)
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.
![Page 7: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/7.jpg)
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
![Page 8: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/8.jpg)
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
![Page 9: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/9.jpg)
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!
![Page 10: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/10.jpg)
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
![Page 11: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/11.jpg)
Guide to good user stories
Vertical user stories
![Page 12: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/12.jpg)
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
![Page 13: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/13.jpg)
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
![Page 14: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/14.jpg)
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
![Page 15: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/15.jpg)
When is a user story ready for development
criteria clear feasible and testable
Done in backlog refinement activity
![Page 16: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/16.jpg)
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
![Page 17: User Stories](https://reader033.fdocuments.us/reader033/viewer/2022051401/55cf9155550346f57b8cb5bb/html5/thumbnails/17.jpg)
Great product