User Story
•Download as PPTX, PDF•
30 likes•10,033 views
This presentation describe What is the need for user stories in Agile project? What is a story? Why story? What is criteria for a good story? What are not stories? Prerequisite? Knowledge of Scrum and it’s terms
Recommended
More Related Content
What's hot
What's hot (20)
Similar to User Story
Similar to User Story (20)
Recently uploaded
Recently uploaded (20)
User Story
- 1. User Stories - Sunil Kumar
- 2. Agenda What is the need for user stories? What is a story? Why story? What is criteria for a good story? What are not stories? Prerequisite? Knowledge of Scrum and it’s terms
- 3. What problems do user stories address? (mis)Communication!
- 4. Between? Those who want the software Those who build the software
- 8. Resource allocation Need to work together to make it a shared problem.
- 9. Developers Responsibility of resource allocation! May trade quality for additional features May only partially implement the feature May solely take decisions that should involve business side
- 10. Only business shoulders the responsibility Lengthy upfront requirements negotiation and signoff Features are dropped as the deadline nears
- 11. We cannot predict a software schedule!
- 12. As users see software, they come up with new ideas
- 14. Developers have hard time estimating!
- 15. So what do we do?
- 16. Make decisions on information often
- 17. Spread the decision-making across the project
- 18. This is where user stories come in
- 19. What are stories? 3C
- 20. Story Card Written on Note cards Should have estimates, notes etc No jargon Written in direct speech
- 21. Conversation! Details behind the story Emerges when team talks with Product owner, customer / customer proxy
- 24. A user can view information about each job that is matched by a search
- 26. Conversation?
- 28. What is an Epic? A user can search for a job A company can post job openings
- 29. Theme?
- 31. Words are imprecise! Main dish comes with soup or salad and bread (Soup or salad) and Bread? (Soup) or (Salad and bread)? The User can enter a name. it can be 127 characters Must the user enter a name? Can it be other than 127 chars?
- 32. Words are imprecise contd… The system should prominently display a warning message whenever the user enter invalid data What does should mean? What does prominently display mean? Is invalid data defined elsewhere?
- 33. Stories shift the focus from writing to talking “You built what I asked for, but it’s not what I need”
- 34. Stories are equally understandable by developers and customers
- 36. Stories are right size for planning
- 37. Stories support participatory design
- 38. Stories emphasize user’s goals not system attributes What are we building? The product shall have a gas engine The product shall have four wheels The product shall have rubber tyre mounted to each wheel The product shall have a steering wheel The product shall have a steel body
- 39. What if we had stories instead?
- 40. Don’t forget the purpose The story text we write on cards is less important than the conversations we have
- 41. User Story Template “As a <Some Role> I want <Some Need> So that <Some Benefit>”
- 42. A “real” Story card As an <unregistered user of [an online game]> I want <to setup a trial team> So that <I can try the game without signing up>
- 43. Advantages of “As a user, I want” user story template With “I want” phrase, person more closely identifies with stories and person’s mind goes instantly to imagining as he or she is such-and-such. Helps in prioritizing story. The product owner is forced to understand the feature, benefits and value (“so that” phrase) This format is a best practice towards executable requirements and a domain specific language
- 44. What is criteria for good story? Independent Negotiable Valuable to users or customers Estimable Small Testable
- 45. Independent Introduce as little dependencies as possible Break up work in vertical layers Dependent stories should not be done in same sprint
- 47. Company can pay for a job posting with a visa card
- 48. Company can pay for a job posting with a master card
- 49. Company can pay for a job posting with an American Express
- 50. Good
- 51. Company can pay for a job posting with a credit card
- 52. Also good
- 53. Company can pay for a job posting with one type of a credit card
- 55. Valuable If we can’t specify value of a story we probably don’t know enough about it
- 57. Not
- 58. All connections to the database are through a connection pool
- 59. All error handling and logging is done through a set of common classes.
- 60. If there’s a technical story put it in terms the business can understand
- 61. Up to fifty users should be able to use the application with a five-user database license
- 64. Story is too big* Yes, it is a word!
- 65. Small Size does matter A user can plan a vacation (EPIC) Based on team and capabilities and technology in use. Allows more granular tracking of progress Easier to estimate (less error prone)
- 66. Testable If you can’t test it, how do you know It’s done? It’s done right? Should have done criteria Business criteria Technical Debt Cross-cutting concerns Regression failures allowable?
- 68. A novice user is able to complete common workflows without training
- 69. A user must not have to wait long for a screen to appear.
- 70. New screens appear within two seconds in 95% of all cases.
- 71. Strive for 99% automation
- 72. Automate on the code not just the UI.
- 73. Fit is good (Fitnesse)
- 75. Screen mockup (not story)
- 76. Use case (not story)
- 77. UML diagrams (not story)
- 79. Some guideline for story writing
- 82. A resume can be posted by a job seeker
- 83. Good
- 85. But they can suggest
- 86. Which maybe is write them then get signoff
- 87. Offer advice
- 91. Questions?
Editor's Notes
- Software requirements is a communication problem.Software Engineer != Construction.Building software is side effect of discovering the customer’s problems.
- The communication problem is between those who want the software and those who build the software
- If either side dominates the business loses.
- The functionality and dates are mandated with little regard for reality or whether the developers understand the requirements.
- … technical jargon replaces the language of business and developers lose the opportunity to learn from listening.
- We need a way of working together so that resource allocation becomes a shared problemProject fails when the problem of resource allocation falls too far to one side
- We cannot predict a software schedule. Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain (Wikipedia). Estimation is prediction NOT planning. Typical first estimate is off by factor of 4 0.25x to 4x. They should be naturally realigned as we gather more information during the project.
- Human beings in general are bad at absolute estimates. They are good at relative estimation.
- We make decisions based on the information we have, but do it often
- Rather than making one all-encompassing set of decisions, we spread decision making across project
- Card – Stories are traditionally written on note cards. Cards may be annotated with estimates, notes, etc
- Conversation – Details behind the story come out during conversations with product owner
- Confirmation – Acceptance tests confirm the story was coded correctly
- Stories that are big are called EPIC. They can potentially be broken down into smaller stories. Epics are listed in the product backlog for future sprints / iterations.
- A collection of related user stories
- If the requirements are written down then At best the customer will get what was written. Customer may make lot of assumptions while writing the requirements.
- Stories support and encourage iterative development. Encourage deferring the detail until you have the best understanding of what you really need.
- Intentionally left blank.Think what points might go in this slide
- A user story is request for valuable stuffPromise for future conversationIn scrum it goes into product backlog item.
- Identifies who the user is, what they want to do and why?
- This mnemonic helps determining whether a story is acceptable or not.
- If there is lot of dependency it might suggest we are breaking work in horizontal layers (in tiers – Database, db layer, business logic, UI)Agile methodology suggest to breaking work in vertical layers (slice through tiers)If not independent, it make product backlog difficult to manage multiple layers of dependency.If dependency is unavoidable, then prioritize dependent stories after the stories they depend on.Or use mocking architecture, decouple dependency.
- Story should be request for value.Should not dictate what they want.Advantage is it will avoid biased opinion Eg: By how many runs will England win against India. This mean we are assuming that England will win.Too much detail turns user story into contract which is taking away self-organization capability of scrum team.
- Identifying value is key part of writing the story.Everything in scrum is value driven.
- Common reasons why they’re not estimableLack domain knowledgeCan discuss with business people and learnLack technical knowledgeCan spike on the story to learn more about itTwo stories, one for the spike one for the real workStory is too big – cannot commit to big stories.Sometimes useful to write the epic to be a placeholder for some glossed over part of a system.Pulled from thin air estimate!Or break it down.
- Small stories are easier to estimate.A story that is too big to do in single sprint is an “EPIC”
- Cross cutting concerns: compliance with corporate needs. External regulations.