agile requirements - journey of a user story

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