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.
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.
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.
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.
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
