Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
User Story Life Cycle
Transcript of User Story Life Cycle
for Team Consumption Shape Epics into Small
stories Ensure that stories are Testable & Estimable for each scenario Write
Epic stories The Coach Testable Decide whether goal of the story is met
by writing the test early User Story QA ensures stories are: Product Owner + QA + Team member Coach optionally could shadow those typical User Story life cycle meetings to facilitate The Coach Product Owner writes Epic stories that are: Who own this stage? Details co-created by customer & team during development.
A User Story is not a contract for specific functionality
Flexibility through vagueness
Lack of overlay constraining and too-detailed requirements enhances teams and business ability to make tradeoffs between functionality and delivery dates Negotiable Making each vertical slice through architecture valuable to the customer supports pay-as-you-go attitude toward infrastructure
Create stories that are vertical slices of value to the user
Developers often have an inclination to work on only one layer at a time and "get it right"<- WRONG Valuable Architect and Team member negotiate with PO to create vertical slices of large stories along architectural layers, to shape: Product Owner + Architect + Team Member Life Cycle Resources Team receives well packaged user stories Product Owner + Team Negotiable Valuable Small & Independent stories Small Small user stories provide more
agility and productivity through
increased throughput and
decreased complexity Details can be elaborated through
conversations with customer Independent Stories are valued independently
meaning each story can deliver
value independently To schedule and implement in
them any order Strive to eliminate 0-value technical
functional dependencies Eliminate dependencies by intelligently
splitting stories Testable Estimable with scenarios for each user story & Additional story split along scenarios and
acceptance criteria may occur Stories don't get into an iteration if they can't get out. Framing stories with clear boundaries will help teams and the business share expectations of the output and avoid big surprises. Sizing helps the customer rank & schedule story's implementation If a user story is too large to estimate, it should be split into smaller ones. If a user story is too uncertain to estimate, them a technical or functional spike story can be used to reduce uncertainty. Estimating user stories draws out any hidden assumptions, missing acceptance criteria, and clarify a shared understanding of the story. Team negotiates user stories with the Product Owner Team sizes story for understanding and provides estimate Coach will aid PO in writing good user stories,
when user stories are not properly written Who own this stage? Product Owner Who own this stage? Who own this stage? Agile in Pills