User stories — how to cook a cat?


Published on

It's told that if you don't like a cat you just don't know how to cook it. It's the same if we're talking about estimating and prioritizing user stories. This time we will back to unfinished the subject about bad examples of user stories and the stuff which one don't know how to treat as the user story. We will talk about which role, when and how work with user story and cover the main principles of user stories (no)estimations.

- What is and what is not a user story?
- Who, when and why — roles and ceremonies.
- To estimate or not to estimate?
- Case studies/practice

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User stories — how to cook a cat?

  1. 1. Vladimir TarasowHow to cook a cat?User Stories
  2. 2. Vladimir TarasowAbout:
  3. 3. User Story
  4. 4. User StoryRepresent a description of a “solution” —from a functional point of view.Should cut through all the layers ofthe architecture.Must contain also Acceptance Criteria thatdescribes how the user of the story wouldaccept the implemented functionality.
  5. 5. INVEST ModelIndependent. Easier to plan, if it has nodependencies.Negotiable. Details added via collaboration.Valuable. Provides value to the customer.Estimable. If its too big or too small, youcant estimate it.Small. Can be done in less than a week bythe team.Testable. Good acceptance criteria.
  6. 6. What is andwhat is nota User Story?
  7. 7. Bad User Story Example #1User Story: Design brochure layout.Drawbacks:● Hard to say is it Independent or not.● No business Value.● This is a task representing a horizontalarchitectural layer or phase.● It can not be analyzed.
  8. 8. TaskThe part of User Story which has no valueby itself.You cant demonstrate the task by its own.Understandable User Stories can be dividedinto tasks at any moment.Dividing into tasks helps to estimate UserStory and expose additional work amount.
  9. 9. Bad User Story Example #2User Story: As a cinema fan I want to feelspatial movement so that I will immerseinto action deeper.Drawbacks:● Not Small.● Not Estimable.
  10. 10. Bad User Story Example #2Thats how this story looks like in real life.Can you explain how to reach it?
  11. 11. EpicAn Epic is a big story.It entails a sequence of actions that followa specific order.Should be broken down and specified.
  12. 12. ThemeIs a collection of related user stories.Describes a view of a tangible product oran abstract goal.Often used to organize stories intoreleases.Often used to organize user stories so thatvarious sub-teams can work on them in-parallel.
  13. 13. Bad User Story Example #3User Story: Verify that text entered in"password" text box is masked.Drawbacks:● No business Value.● Nothing to negotiate.● Doesnt cut through all the layers of thearchitecture.
  14. 14. Test CaseIs not an acceptance criteria.But derived from acceptance criterias.Are specific steps to check a featurebehaves as expected.Not necessary to plan an iteration.Can be written in the same iteration as thecode, before or in parallel with developingthe code.
  15. 15. Bad User Story Example #4User Story: After the user has selecteditems to purchase and then order theitems. The user will provide payment andshipping information. The system willrespond with confirmation of the order anda tracking number that the user can use tocheck on order status in the future. Thesystem will also provide the user with anestimated delivery date for the order.
  16. 16. Use CaseIs a list of steps defining interactionsbetween a role and a system, to achieve agoal.Сonsist of two components: use casediagrams and the text.Typically contains more details thanstories and traditional requirements.
  17. 17. Iterative & incremental developmentRational Unified Process (RUP).It often uses Use Cases which are similar toUser Stories.Its iterative development process.It must meet all the objective in the end ofrelease.
  18. 18. Iterative & incremental development
  19. 19. Bad User Story Example #5User Story: As Product Owner, I want a listof highly-rated restaurants on thebrochure.Drawbacks:● It’s not only about you!● Not Valuable enough. Focus on your endusers and stakeholders.
  20. 20. Technical StoryNeeds to be done but cant be delivered.Doesnt directly relate to any specificstories.Havent direct value to the product owner.Try to avoid tech stories.Transform a tech story into a normal storywith measurable business value or into atask within another story.
  21. 21. BugPO gets the most high priority item frombug tracking system and put it into productbacklog.PO creates stories that refer to items frombug tracking system.Bug-fixing is considered to be outside ofthe sprint.
  22. 22. Who?What?When?
  23. 23. StakeholdersCant affect user stories directly.However…Create requirements.Define the value.Define priorities.
  24. 24. Scrum MasterCant affect user stories directly.However…Helps PO to organize SprintPlanning Meeting.Helps the Team to developStories by removingimpediments.Helps the Team in preparingthe Review Meeting.
  25. 25. Product OwnerAdds or removes User Stories.Prioritizes User Stories.Selects User Stories to bedone during the nextiteration.Breaks down User Stories andEpics.Accepts produced UserStories.
  26. 26. TeamEstimates User Stories forthe iteration.Breaks down User Stories totasks.Develops User Stories.Apply quality during UserStory development.Demos User Stories to PO.
  27. 27. The Life ofUser Story
  28. 28. The Life of User Story
  29. 29. DEEPDetailed AppropriatelyEstimatedEmergentPrioritized
  30. 30. The Life of User Story
  31. 31. Splitting User StoriesBy variations in data.By workflow steps.By data entry methods.By business rules variations.By operations (CRUD).By major effort.By simple/complex cases.Defer performance.
  32. 32. The Life of User Story
  33. 33. The Life of User StoryCreating and adding details torequirements might take 1-2 years.MMFs and Epics are used for medium termplanning from 1/2 to 1 year.User stories is for short term planning fromabout 4 to 8 weeks.
  34. 34. Thank You!Please, leave feedback!
  35. 35. Materials used in the presentation:● User Stories, Epics and Themes by Mike Cohn● User Stories by Mark Levison and Charles Bradley● When To Write Story Tests by Rachel Davies● Basic use case template by Alistair Cockburn● IBM Rational Unified Process from Wikipedia● How To Split User Stories by Dan Puckett● Business Value Game by Andrea Tomasini● #NoEstimates Part 1: Doing Scrum without estimates by Neil Killick● Purpose Of Estimation by Martin Fawler● Iterative development by Dutchguilder● Photo by Geoff Gallice● Photo by Chiara Vitellozzi● Illustrations by Vladimir TarasowCredits
  36. 36. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of thislicense, visit