Story of user story
13 likes1,744 views
The document discusses the concept of user stories in agile methodologies, detailing their history, structure, and guidelines for effectively writing and prioritizing them. It emphasizes the importance of shared understanding and communication in defining user stories, as well as techniques for estimating effort and complexity involved in development. Additionally, it covers methods for slicing user stories, defining readiness and completion criteria, and various prioritization strategies.
![User Story-Templates
As a <WHO|ROLE>
I want <WHAT|FEATURE>
So that <WHY|PURPOSE>
OR
Given [context]
When [event]
Then [outcome]](https://image.slidesharecdn.com/storyofuserstory-160630043915/85/Story-of-user-story-5-320.jpg)
![Story Points
• Story Points are the unit of measurement for expressing the overall size of a user story,
feature, or other piece of work.
• The number of story points associated with a story represents the overall size of the story.
• Either Doubles OR Fibonacci Series
Non Linear Scale - Fibonacci Series [1,2,3,5, and 8]
Non Linear Scale - Doubles [1,2,4, and 8]](https://image.slidesharecdn.com/storyofuserstory-160630043915/85/Story-of-user-story-25-320.jpg)
Story of user story
- 1. Story of User Story Balaji Sathram, CSP, PMI-ACP. Scrum master, Sabre.
- 2. Agenda • User Story-History • User Story - Brief • User Story-Templates • Writing good user stories • Slicing user stories • To maintain good user stories • Additional Terms • User Story - Prioritization • User Story - Estimation
- 3. User Story-History • Comes from XP (eXtreme Programming) • 1999: Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition • Documenting requirements to Explaining (Tell story about what you want): Building a common and shared understanding. • People started following it. But The sad part of the whole episode is: instead of telling stories, people started writing stories. • Organizations started documenting user stories: "shared documents are not shared understanding"
- 4. User Story - Brief What is User Story: • A concise written description of a piece of functionality that will be valuable to a user (or product owner) of the software. • All about the user’s goals • Carries the value stream to the user • It contains: • Value: Requirement of a customer • Cost: an understanding of what it takes to build • Validation: that you understand what is happening
- 5. User Story-Templates As a <WHO|ROLE> I want <WHAT|FEATURE> So that <WHY|PURPOSE> OR Given [context] When [event] Then [outcome]
- 6. Story Inputs
- 7. XP Stories – Ron Jeffries – 3Cs • In 2001 • Card: Write stories on a card. Just enough to identify the requirement. • Conversation: Most of the requirement is communicated through a conversation. Information can be stored elsewhere. The story is a holder for these. • Confirmation: “How will we know we’ve done that.” We also need an acceptance test.
- 8. User Story Description • It is written down on a note card (e.g. 3x5 inches or 8x13 cm) • Start with a title. • Add a concise description using the templates. • Add other relevant notes, specifications, or sketches • Before building software write acceptance criteria (how do we know when we’re done?)
- 9. Writing good user stories • Independent – User Stories should be as independent as possible. • Negotiable – A User Story is not a contract. It is not a detailed specification. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team • Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks. • Estimable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed. • Small – User Stories should be small. Not too small and not too big. DONE in one iteration • Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested. if you can’t test it, you don’t know when you are done
- 10. Slicing user stories • Breaking them down
- 11. Slicing User Stories • Split by workflow steps • Split by business rules • Split by happy/unhappy flow • Split by input options / platform • Split by test data or data types or parameters • Split by operations(CRUD) • Split by test scenarios/test case • Split by Roles • Split by external dependencies • Split based on Mock/Real services • Split based on acceptance criteria • Split based on Usability
- 12. Some Additional Useful Terms • Definition of Ready • Definition of Done • Acceptance Criteria • Theme and Epic
- 13. Definition of Ready From Team to Product Owner • No Open questions • Test data collected • No technical dependencies • Workflow figured out • Acceptance criteria understood • Estimated • Has some business value • Sized appropriately
- 14. Definition of Done From Team to the Team • Architectural Review Complete • Code Review Complete • Unit Tested • Test Scenarios Review with BA/PO/Team members • QA tested • PO/BA Acceptance • No Priority 1 or Priority 2 bugs • Integration • Known deployment & Rollback plan
- 15. Acceptance Criteria From Product Owner to the Team • Agreement between the team and the PO on when the story is accepted
- 16. Theme and Epic
- 17. PRIORITIZATION
- 18. Prioritization • High-Medium-Low • MoSCoW • Kano Analysis • 1-2-3-4-5 • Stacked Ranking • Impact Analysis
- 19. MoSCoW • A method to prioritize requirements popularized in the DSDM (Dynamic systems development method) community is MoSCoW • Must Have, Should Have, Could Have and Won’t Have
- 20. Kano Analysis • Kano Analysis is a quality measurement tool used to prioritize customer requirements based on their impact to customer satisfaction. According to the Kano Model (developed by Dr Noriaki Kano in the 1980s), a product or service can have three types of attribute (or property): • Musts: Which customers expect to be present in a product. • Satisfiers: Which are not absolutely necessary, but which are known about and increase the customer's enjoyment of the product. • Delighters: Which customers don't even know they want, but are delighted when they find them.
- 21. Impact Analysis • For every user story, give impact points based on below questions • What is the impact it is creating if it is implemented • What is the impact it is creating if it is not implemented • Multiply both the values which will result in impact score for the user story • Higher the score higher the impact
- 22. ESTIMATION
- 23. Estimation
- 24. User Story - What do we Estimate? Complexity Uncertainty Effort
- 25. Story Points • Story Points are the unit of measurement for expressing the overall size of a user story, feature, or other piece of work. • The number of story points associated with a story represents the overall size of the story. • Either Doubles OR Fibonacci Series Non Linear Scale - Fibonacci Series [1,2,3,5, and 8] Non Linear Scale - Doubles [1,2,4, and 8]
- 26. Estimation Techniques • Agile Relative Sizing • Ideal Days • Planning Poker • Wideband Delphi • Affinity Estimating
- 28. Ideal Days How long something would take if • It’s all you worked on • you had no interruptions • and everything you need is available Factors Affecting Ideal Time: Training, Email, Reviews, Interviewing, Demonstrations, Meetings, Sick Time, Phone, Bug Fixing, Management review
- 29. Planning Poker An iterative approach to estimating Steps: • Each estimator is given a deck of cards, each card has a valid estimate written on it • Customer/product owner reads a story and it’s discussed briefly • Each estimator selects a card that’s his or her estimate • Cards are turned over so all can see them • Discuss differences (especially outliers) • Re-estimate until estimates converge
- 30. Wideband Delphi Is a process that the team can use to generate an estimate Process: • Choose the team • Kick off meeting • Individual preparation • Estimation session • Assemble tasks • Review results
- 31. Affinity Estimation (Lowell Lindstrom) Affinity estimating is a technique many teams use to quickly and easily estimate (in story points) a large number of user stories. • Product backlog is provided by the product owner • Team members are expected to size each item relative to other items on the wall considering the effort involved in implementation • Stories are arranged horizontally
- 33. Thank you