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?”
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
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?
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
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
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
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
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
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)
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
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