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 - Journey of a User Story


Published on

This talk is an experience report on how we've used agile and lean requirements practices like story mapping, user stories, mockups, scenarios and sprint review feedback, on a real project.
It is not theory-based, but rather tells the warts-and-all real story, with a number of photos and screenshots, and detailed discussions of benefits and drawbacks, to give an idea of what it really felt like.
YouTube video of the talk:
Talk description:
How do agile requirements work? Where does documentation fit in?
For many of us, the transition from the security of upfront analysis and detailed specification documents to ‘doing agile’ and embracing the process of discovery is a terrifying prospect. Agile theories don’t readily address the concern ‘how will we know where we’re going if we don’t start with a Business Requirement Specification?’
In this talk I will take the audience on the journey of a real customer requirement from inception to delivery, seeing how the user stories evolved over time.
Starting at the beginning I’ll take you through how the user need was elaborated into features, stories and scenarios to become released software, and how feedback from customer interaction continued to shape it.
As we go along, we’ll see how the documentation built itself, and how it compares with the traditional Business Requirement Specification document.
With a little bit of theory and a lot of real world experience, we’ll also cover questions like “How can we be sure we’ll cover everything?” and “How do we overcome our uncertainty?”

Published in: Technology, Business

Agile Requirements - Journey of a User Story

  1. 1. Agile Requirements The documentation that built itself Cara Turner South Africa Agile Coach | User Group Chairman | Facilitation Fanatic
  2. 2. About You Who’s working on agile projects? Waterfall? Something Else? When do you document requirements?
  3. 3. Why do we do Upfront Analysis? “It depends …”
  4. 4. About me … and requirements Late Expensive FRS RUP BRS Co-ordination? Hard to imagine doing things differently
  5. 5. About me … and requirements Change Requests Information changes? Hard to imagine doing things differently
  6. 6. About me … and requirements Spec? Scrum & Kanban What do users really want? (Less) hard to imagine doing things differently
  7. 7. The feedback loop
  8. 8. Agile Requirements Factors Whole team participates, PO owns Start with an overview of the whole application A sprint-and-a-half ahead ‘Right detail at the right time’
  9. 9. ‘Right Detail at the Right Time’ What does that mean? Deliberate Discovery: decreasing uncertainty over time Real Options: make binding decisions at the right time
  10. 10. ‘Right Detail at the Right Time’
  11. 11. Agile Requirements Elements Story Mapping Product Backlog Story Cards, Mockups & Scenarios ‘Doing the Work’ Grooming & Release Planning
  12. 12. Agile Requirements Artefacts
  13. 13. So, on to Our Story
  14. 14. The Problem We have collections lists Our application for administering them is out of date ‘Edge case bloat’ over 10 yrs Consumer behaviour has changed Much of it is manual Waste of time Can’t optimize focus Tech out of date High cost to change
  15. 15. Changes Required ‘Edge case bloat’ over 10 yrs Change what appears in the lists Much of it is manual Automate assigning of lists Make it easier to work accounts
  16. 16. Team Ingredients PO Team EXP EXP MID MID JNR JNR EXP D A D A D A No systems knowledge on the team Access to ‘Systems Analyst’ ‘As is’ systems rules documents SM Agile Requirements Many techniques are new Where to start?
  17. 17. At the Whiteboard
  18. 18. Story Mapping
  19. 19. The Persona
  20. 20. The Story Map Assign Lists Action Accounts
  21. 21. Acceptance Criteria
  22. 22. Benefits & Drawbacks Benefits  Everyone saw the whole picture unfold  Gut feel of size  Sponsor was heard  Key drivers clarified  Strong identification with Persona – Shaped future grooming Drawbacks  Unfamiliar process  Not everyone spoke – New to all the devs – „Boss‟ in the room  Sense of duplication of the rules “specification” doc  Sequential activities imply workflow  Persona incomplete – no customer persona
  23. 23. Documentation      Personas Key business drivers Big picture: whole and the parts Verbal culture: tacit knowledge captured Photos - document experience Journey of a User Story – SUGSA 2013
  24. 24. Backlog Creation Features Narrative
  25. 25. Benefits & Drawbacks Benefits  Complete picture  Saved in central location & accessed via wiki  Narrative format from start –   “In order to… As a… I want…” Easy to link to features Easy to add values, then estimate release size Drawbacks  Google Spreadsheet: hard to track changes, manual numbering  Some high priority / concern issues created as Features  Acceptance Criteria captured as stories  Tempting to use spreadsheet for grooming
  26. 26. Documentation     Release Overview All the user stories at a high level Feature -> Stories -> Acceptance criteria Narrative: benefit / value clear-ish Journey of a User Story – SUGSA 2013
  27. 27. Story Card Creation
  28. 28. Benefits & Drawbacks Benefits  Low effort to move & change  Provided focus for grooming & sprint planning  Really did function as a record of a conversation  History: easy to update with grooming & sprint info Drawbacks  (Bit of a) pain to handle manual cards  Didn‟t refer to the “as is” rules documents much  Not visible: lived in a draw, not on the wall
  29. 29. Documentation    Visual indicator of scope Grouped by feature Card for each user story – Story ID – Title – Size – Grooming notes – Feature (later) Journey of a User Story – SUGSA 2013
  30. 30. Ordering the Backlog Risks Assumptions Dependencies Unknowns
  31. 31. Doing the Work - Sprint 1
  32. 32. Ordering the Backlog Risks Assumptions Dependencies Unknowns Priority: what do we need to prove early? What can we delay?
  33. 33. Release Grooming - RADU
  34. 34. RADU
  35. 35. Documentation  Ordering principles: – Risks: Prove early – Technical Dependencies – Feature Dependencies    Assumptions & Unknowns to clarify „Readiness‟ indicator Manually track changes in information Journey of a User Story – SUGSA 2013
  36. 36. Release Planning
  37. 37. Ordering Assigning lists: Low risk, low effort Highest risk, Do first: MonthEnd changes Then prove: Lists display accurately Then prove: Actions on account correct … then Assign lists
  38. 38. Release Information
  39. 39. Sprints per Release
  40. 40. Documentation      Ordered, prioritized backlog Best guess estimate of feature sizes Best guess release size 2 sprints: team velocity data point Approximate release duration Journey of a User Story – SUGSA 2013
  41. 41. Grooming: Mock-ups
  42. 42. Benefits & Drawbacks Benefits  Great starting point for technical discussions  Most created after RADU discussion  Easy for users to relate to in grooming  Indication of system flow  Acceptance criteria included by default  Low cost to change Drawbacks  Trying to get it „right‟  Can anchor ideas too soon  Team less inclined to model visually in grooming  PDFs not easily linked to individual stories
  43. 43. Documentation    Page layout and navigation Acceptance criteria, rules, comments Current information: frequently updated Journey of a User Story – SUGSA 2013
  44. 44. Scenarios
  45. 45. Benefits & Drawbacks Benefits  Detailed discussion of system flow  Pre and Post conditions (simpler)  Test data  More visual modelling  Updated mock-ups Drawbacks  Hard to do initially  (Easy to get them wrong)
  46. 46. Documentation      Documented Tests Expected path, alternate paths, fail conditions Better stories Test data: automation Backlog, mockups and RADU updated Journey of a User Story – SUGSA 2013
  47. 47. Sprint Review
  48. 48. Benefits & Drawbacks Benefits  Sponsor and users clear on progress  Immediate feedback  Incorporate small changes in next sprint  Schedule longer changes for Grooming  Generated excitement Drawbacks  Long 1st release cycle (7 sprints) Users lost touch with early features
  49. 49. So how did that all work?
  50. 50. Create Lists
  51. 51. Action Accounts
  52. 52. Assign Lists: Grooming
  53. 53. Assign Lists: Sprint Planning
  54. 54. Assign Lists: Sprint & Feedback
  55. 55. “Just In Time” Requirements  High level scope  RADU, Readiness factor  Sprint-ready detail  “But that‟s changed now”  High quality of “Working software” Journey of a User Story – SUGSA 2013
  56. 56. Learnings    Story Mapping + Scenarios complete the picture No single tool does all the things All the tools: “Living Documentation” … or as close as we‟ve got so far… Journey of a User Story – SUGSA 2013
  57. 57. For the next project..   Will have domain knowledge & known velocity Start with Impact Mapping Clearer goals and personas  Use a backlog management tool Link features, stories, mock-ups, acceptance criteria, scenarios   Integrate „As Is‟ document into grooming More time on scenarios Journey of a User Story – SUGSA 2013
  58. 58. Recommended Reading Agile Requirements: Impact Mapping Lean Designers: Agile Reflections: Story Mapping: Jeff Patton: Behaviour Driven Design: Dan North: Liz Keogh:
  59. 59. Questions? What one thing are you taking away?
  60. 60. Get in Touch Cara Turner Cape Town, South Africa twitter: @cara_faye