agile requirements - journey of a user story
DESCRIPTION
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?”TRANSCRIPT
Agile Requirements
The documentation that built itself
Cara Turner South AfricaAgile Coach | User Group Chairman |
Facilitation Fanatic
Who’s working on agile projects?
About You
When do you document requirements?
Waterfall? Something Else?
“It depends …”
Why do we do Upfront Analysis?
About me … and requirements
Co-ordination?
FRS BRS
RUP
Late
Expensive
Hard to imagine doing things differently
Hard to imagine doing things differently
About me … and requirements
PM / Scrumbut Change Requests
Information changes?
About me … and requirements
Spec?
Scrum & KanbanWhat do usersreally want?
(Less) hard to imagine doing things differently
The feedback loop
Agile Requirements Factors
Start with an overview of the whole application
‘Right detail at the right time’
A sprint-and-a-half ahead
Whole team participates, PO owns
‘Right Detail at the Right Time’
Deliberate Discovery: decreasing uncertainty over time
Real Options: make binding decisions at the right time
What does that mean?
‘Right Detail at the Right Time’
Agile Requirements Elements
Story Mapping
Product Backlog
Story Cards, Mockups & Scenarios
‘Doing the Work’
Grooming & Release Planning
Agile Requirements Artefacts
So, on to Our Story
The Problem
We have collections listsOur application for
administering them is out of date
Tech out of date
Much of it is manualCan’t optimize focusWaste of time
‘Edge case bloat’ over 10 yrs
Consumer behaviour has changed
High cost to change
Changes Required
Much of it is manualAutomate assigning of listsMake it easier to work accounts
‘Edge case bloat’ over 10 yrsChange what appears in the lists
Team Ingredients
No systems knowledge on the team
Access to ‘Systems Analyst’‘As is’ systems rules
documents
Agile Requirements
Many techniques are new
Where to start?
EXP
PO
D A
Team
MID JNREXP JNRMID
AD
EXP
SM
D A
At the Whiteboard
Story Mapping
The Persona
The Story Map
Assign Lists Action Accounts
Acceptance Criteria
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
Journey of a User Story – SUGSA 2013
Documentation
Personas Key business drivers Big picture: whole and the parts Verbal culture: tacit knowledge
captured Photos - document experience
On the wiki!
Backlog Creation
Features Narrative
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
Journey of a User Story – SUGSA 2013
Documentation
Release Overview All the user stories at a high level Feature -> Stories -> Acceptance
criteria Narrative: benefit / value clear-ish
On the wiki!
Story Card Creation
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
Journey of a User Story – SUGSA 2013
Documentation
Visual indicator of scope Grouped by feature Card for each user story– Story ID– Title– Size– Grooming notes– Feature (later)
Photoson the wiki!
Ordering the Backlog
Risks Dependencies
Assumptions Unknowns
Doing the Work - Sprint 1
Ordering the Backlog
Priority: what do we need to prove early?
Risks Dependencies
Assumptions Unknowns
What can we delay?
Release Grooming - RADU
RADU
Journey of a User Story – SUGSA 2013
Documentation
Ordering principles:– Risks: Prove early– Technical Dependencies– Feature Dependencies
Assumptions & Unknowns to clarify ‘Readiness’ indicator Manually track changes in
information
On the wiki!
Release Planning
Ordering
Highest risk, Do first: MonthEnd changes
Then prove: Lists display accurately
Then prove: Actions on account correct
Assigning lists: Low risk, low effort
… then Assign lists
Release Information
Sprints per Release
Journey of a User Story – SUGSA 2013
Documentation
Ordered, prioritized backlog Best guess estimate of feature sizes Best guess release size 2 sprints: team velocity data point Approximate release duration
On the wiki!
Grooming: Mock-ups
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
Journey of a User Story – SUGSA 2013
Documentation
Page layout and navigation Acceptance criteria, rules, comments Current information: frequently
updated
On the wiki!
Scenarios
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)
Journey of a User Story – SUGSA 2013
Documentation
Documented Tests Expected path, alternate paths, fail
conditions Better stories Test data: automation Backlog, mockups and RADU updated
On the wiki!
Sprint Review
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
So how did that all work?
Create Lists
Action Accounts
Assign Lists: Grooming
Assign Lists: Sprint Planning
Assign Lists: Sprint & Feedback
Journey of a User Story – SUGSA 2013
High level scope RADU, Readiness factor
Sprint-ready detail “But that’s changed now”
High quality of “Working software”
“Just In Time” Requirements
Journey of a User Story – SUGSA 2013
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
For the next project..
Will have domain knowledge & known velocity
Start with Impact MappingClearer goals and personas
Use a backlog management toolLink features, stories, mock-ups,
acceptance criteria, scenarios Integrate ‘As Is’ document into grooming More time on scenarios
Recommended Reading
Agile Requirements:Impact Mapping www.impactmapping.orgLean Designers: www.leandesign.frAgile 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
What one thing are you taking away?
Questions?
Cara TurnerCape Town, South
Africa
Get in Touch
krs.co.za sugsa.org.za
twitter: @cara_fayefacilitatingagility.com