Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Requirements Stories and Backlogs


Published on

Introductory session on Agile Requirements, Stories and Backlogs presented for Agile University 2014

Published in: Engineering, Technology
  • You might get some help from ⇒ ⇐ Success and best regards!
    Are you sure you want to  Yes  No
    Your message goes here
  • People used to laugh at me behind my back before I was in shape or successful. Once I lost a lot of weight, I was so excited that I opened my own gym, and began helping others. I began to get quite a large following of students, and finally, I didn't catch someone laughing at me behind my back any longer. CLICK HERE NOW ■■■
    Are you sure you want to  Yes  No
    Your message goes here

Agile Requirements Stories and Backlogs

  1. 1. Class 3 – Agile Requirements & User Stories
  2. 2. 06/04 Agile Values & Principles Ned Horvath/ Mark Spitzer 06/11 Scrum Overview & Roles Kincade Park/ Tracy Whitehill 06/18 Agile Rqmts & User Stories Pat Scherer/Roberto Vasquez 06/25 Release Planning/Estimation Walter Bodwell/Mark Ridlehuber 07/02 Sprint Ceremonies Timothy Balraj / Dan Corbin 07/09 Scrum Simulation Jason Morillo / Ned Horvath 07/16 Kanban & Lean Overview Jay Paulson / Pat Scherer 07/23 Agile Technical Practices David Merryweather/Arpit Gupta 07/30 Retrospectives David Hawks / Arpit Gupta
  3. 3. #AgileAustinU!forum/agile-austin-u
  4. 4. Platinum Sponsors:
  5. 5. Gold Sponsors:
  6. 6. Tonight’s Refreshments Silver Sponsors: Bronze Sponsors:
  7. 7. Pat Scherer  Product Owner (SaaS/Mobile) & Agile CSM Roberto Vasquez  Software Engineer (CSM- CSPO)  Silicon Labs
  8. 8.  Be on time  Turn off / silence your cell phone  Cancellations made 48-hours in advance  Take break in the middle of the session  Talkative people ask more questions to get the entire group talking  One conversation at a time  Positive comments are always welcomed  Raise your hand to speak  Quiet hand raise to grab attention after exercise  Use Roman voting (thumbs up/thumb down) Any proposed changes?
  9. 9. 10 An ever-changing list of desired product features  New features • Defects • Non- functional requirements  Multiple sources and channels  All sizes • Levels of feasibility • Timeframes  Incomplete • Unclear • Conflicting  Unquantified value
  10. 10. 11 What are the characteristics of “good requirements”? Table Discussion Who? Customers, market research, … Why? How much? Reward for delivery What is required? Not how it should be implemented When? Window of opportunity
  11. 11. Assign Estimate Prioritize 12 m Stories Sprint 4 Sprint 3 Sprint 2 Sprint 1
  12. 12. Source: 13
  13. 13. We need a light weight method, so that… Rather than making one all-encompassing set of decisions up front … we can spread decision making across the project based on the latest information Copyright © 2012 Agile Velocity, LLC. All Rights Reserved. AGILE VELOCITY PROPRIETARY 14
  14. 14. As a <WHO> I want <WHAT> So that <WHY>
  15. 15. As a frequent flyer I want to rebook a past trip So that I save time booking trips I take.
  16. 16.  Take a 4x6 card and write a User Story for a feature you recently worked on  Make sure to include the who, what and why 17
  17. 17. Acceptance Criteria: • All previous trips are presented as options for rebooking • Does not permit me to rebook for a date when hotel room or rental car is unavailable • Trip price displayed and charged to card is current, not previous trip price • Process of rebooking takes less than 4 minutes from login to completed transaction
  18. 18. 19 •Independent •Negotiable •Valuable •Estimable •Small •Testable INVEST User-Stories-Cohn-NDC2010.pdf, Mike Cohn
  19. 19. 26 Shift focus from writing to talking • If you begin with writing detailed requirements, then at best you will get what was written, not necessarily what you want. Stories are understandable by both developers and customers Support and encourage iterative development Stories are the right size for planning User-Stories-Cohn-NDC2010.pdf, Mike Cohn
  20. 20. Assign Estimate Prioritize 27 m Stories Sprint 4 Sprint 3 Sprint 2 Sprint 1
  21. 21. An ordered list of ideas (stories, defects, epics) Supports the product vision Managed by the Product Owner Reprioritized before each Sprint Estimated by the Development Team 28
  22. 22. Rank/ID Title Estimate 1. Reservation Cancellation for Premium Members 5 units 2. Confirmation email for Cancellations 3 units 3. French Version 30 units 4. Rental Car Reservations 60 units 5. Book Flights 200 units 29
  23. 23. 30 100 40 100 100 20 2013 13 8 20 813 5 3 21 5 321 51 2 3 1 2 1 1 ProductBacklog Epics Large Lower Priority Future Release Backlog Items (What is Requested) Estimated in Points Small – Sprint Sized Detailed Higher Priority 2-3 Sprints Worth SprintBacklog Tasks (How to Get it Done) Estimated in Hours Tasks Required to Complete Backlog Items Sized Less than a Day Individual Workable Items Release
  24. 24. 31 Backlog Refinement Class Exercise 1. Is this an Epic, Story or Task? 2. How would you make the epic, story or task clearer? (Refine it.) 3. What is the approximate effort? (Consensus) 4. Share your example, process and what you learned.
  25. 25. The Product Owner should be constantly refining the Backlog • Change items • Add items • Delete items • Break big items into smaller ones • (deleting the big one) • Re-prioritize • Add details • De-prioritize items to make room for new items 32
  26. 26. Prior to Each Sprint 1. Determine readiness for next Sprint 2. Break down near term stories 3. Estimate any new stories Separate meeting - weekly or bi-weekly Attended by whole Team and driven by Product Owner 33
  27. 27. Assign Estimate Prioritize 34 m Stories Sprint 4 Sprint 3 Sprint 2 Sprint 1 Next week: Release Planning and Estimation