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: http://www.youtube.com/watch?v=iUIWLNiGYEk 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?”

1. Agile Requirements
The documentation
that built itself
Cara Turner
South Africa
Agile Coach | User Group Chairman | Facilitation Fanatic

2. About You
Who’s working on agile projects?
Waterfall? Something Else?
When do you
document requirements?

3. Why do we do Upfront Analysis?
“It depends …”

4. About me … and requirements
Late
Expensive
FRS
RUP
BRS
Co-ordination?
Hard to imagine
doing things differently

5. About me … and requirements
Change
Requests
Information
changes?
Hard to imagine
doing things differently

6. About me … and requirements
Spec?
Scrum & Kanban
What do users
really want?
(Less) hard to imagine
doing things differently

7. The feedback loop

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. ‘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. ‘Right Detail at the Right Time’

11. Agile Requirements Elements
Story Mapping
Product Backlog
Story Cards, Mockups & Scenarios
‘Doing the Work’
Grooming & Release Planning

12. Agile Requirements Artefacts

13. So, on to Our Story

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. 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. 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. At the Whiteboard

18. Story Mapping

19. The Persona

20. The Story Map
Assign Lists
Action Accounts

21. Acceptance Criteria

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. 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. Backlog Creation
Features
Narrative

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. 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. Story Card Creation

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. 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. Ordering the Backlog
Risks
Assumptions
Dependencies
Unknowns

31. Doing the Work - Sprint 1

32. Ordering the Backlog
Risks
Assumptions
Dependencies
Unknowns
Priority: what do we need to prove early?
What can we delay?

33. Release Grooming - RADU

34. RADU

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. Release Planning

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. Release Information

39. Sprints per Release

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. Grooming: Mock-ups

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. Documentation



Page layout and navigation
Acceptance criteria, rules, comments
Current information: frequently updated
Journey of a User Story – SUGSA 2013

44. Scenarios

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. 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. Sprint Review

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. So how did that all work?

50. Create Lists

51. Action Accounts

52. Assign Lists: Grooming

53. Assign Lists: Sprint Planning

54. Assign Lists: Sprint & Feedback

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. 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. 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. Recommended Reading
Agile Requirements:
Impact Mapping www.impactmapping.org
Lean Designers: www.leandesign.fr
Agile Reflections: www.agilereflections.com
Story Mapping:
Jeff Patton: http://agileproductdesign.com
Behaviour Driven Design:
Dan North: http://dannorth.net/introducing-bdd/
Liz Keogh: http://lunivore.com/media

59. Questions?
What one thing are you
taking away?

60. Get in Touch
Cara Turner
Cape Town, South Africa
twitter: @cara_faye
facilitatingagility.com
krs.co.za
sugsa.org.za