![Michelle D’Souza [email_address] Brandon Byars [email_address]](https://image.slidesharecdn.com/torontopresentation-windows-091101204917-phpapp01/85/Life-Cycle-of-an-Agile-User-Story-1-320.jpg)
![Michelle D’Souza [email_address] Brandon Byars [email_address]](https://image.slidesharecdn.com/torontopresentation-windows-091101204917-phpapp01/85/Life-Cycle-of-an-Agile-User-Story-19-320.jpg)
Life Cycle of an Agile User Story
- 1. Michelle D’Souza [email_address] Brandon Byars [email_address]
- 3. Card Conversation Confirmation As a nurse, I want to have to enter my password before seeing patient data, so that we don’t disclose patient information to unauthorized users. As a <role> I want <feature> So that <business value>
- 4. Independent Negotiable Valuable Estimable Small Testable
- 5. Story Points Size matters, not duration Story points are relative Size can be based on several factors Ideal Days
- 6. T-Shirt Sizing (S, M, L) Exponential (1, 2, 4, 8) Fibonacci series (1, 2, 3, 5, 8)
- 7. 1 – Rhode Island 8 – Texas 2 – Ohio 3 – Nebraska 5 – Nevada 3 / 5 - Oregon
- 8. Moderator: Reads Story Description Ask moderator questions Pick estimate card Show cards simultaneously Discuss Low / High estimates Consensus (OR Pessimist wins!) No bluffing
- 9. As a Customer, I want to log out 1 As a Marketing Manager, I want to display the top 5 Books that are on special every week, So that I can promote company sales offers 8
- 10. As a Customer, I want to add a book to my Shopping Cart
- 11. As a Sales Manager, I want to see the number of orders completed per month, So that I can track online sales numbers
- 12. As a Customer, I want to search for a book by title, So that I can find a book quickly online
- 13. As a Customer, I want to store my credit card online, So that I can make multiple purchases quickly
- 14. As a Customer, I want to fill in a Suggestion Form So that I can leave feedback for the vendors
- 15. As a Customer, I want to delete a book from my Shopping Cart So that I can remove unwanted items from my cart
- 17. Yesterday’s weather Commitment-driven - Add story one-by-one till team cannot commit to more
- 18. Given I am logged in as a user in the administrator role And There are 3 vendors When I go to the manage vendors page Then I should see the first 3 vendor names Given /there are (\d+) vendors/i do |n| Vendor.transaction do Vendor.destroy_all n.to_i.times do |n| Factory.create(:vendor, :business_name => "Vendor #{n}") end end end
- 19. Michelle D’Souza [email_address] Brandon Byars [email_address]
Editor's Notes
- #3: Traditional approach has answered the question of why we got requirements wrong by pushing for more and more precise specification, ending with reams of paper that nobody ever read. The XP approach went the other way. What if we can NEVER specify a requirement precisely enough that there won’t be this kind of ambiguity? Maybe the problem is that we’re just afraid to talk to each other…
- #4: The original idea was to shrink the requirement down to its essence. BY saying that a story had to fit on a physical 3x5 index card, you limit what you can write, forcing a conversation to fill in the gaps. The model of devs working in cubicles with the lights turned off doesn’t work with user stories. There’s a recognition that the requirement will always be incomplete, and face to face conversation is the most effective medium for managing the ambiguity. We’ll talk about confirmation later, but the idea is to try and specify completion criteria so the developer can know when they’re done. If you can’t put your requirement on a post-it, you need a smaller post-it Canonical user story format – we follow it on most of our thoughtworks projects. Most requirements techniques focus only on the middle bit – the actual meat of the requirement. One of the key advantages of user stories is that they provide business context – we see both who it’s valuable for, and why it’s valuable. Requirements aren’t thrown over a wall with no questions allowed – everybody is part of the process to deliver the best application you can, so even lowly devs can question stories – and having the business context specified provides the necessary basis for a productive conversation. You can even leverage the format in creative ways to manage what have traditionally been called nonfunctional requirements – as a member of operations, I want monitoring, so that I can know when something’s going wrong to better manage our SLA’s.
- #7: Business understands that 8 is much bigger than 1 as opposed to a linear scale.
- #8: Placing stories into buckets Law of big numbers
- #9: Estimates not based on single person Show simultaneously because people don’t dominate
- #18: Product owner identifies high priority Talk about tasks Split stories (Consistency more important than accuracy) Split stories with customers collabratively Commitment driven: Devs eyes get bigger than ability to deliver
- #19: The given/when/then format maps nicely to how most test frameworks work. Typically, a test of some sort has a setup phase, a phase where you actually perform the thing you want to test, and a verification phase. The same is typically true even for manual tests.