Scenarios and Stories
Managing the Backlog
How NOT to Measure Progress
Common measures
Hours of effort
Lines of code
Pages of documentation (requirements or design)
These deliver not a single bit of value to the user
If the user can't eat it, it's not food.
User Stories
A story is a unit of real user value
User stories are NOT requirements
They are just reminders for future discussion
Stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable (INVEST)
Backlogs
A prioritized queue of user stories to be done
Importance defined by client
No due dates!
Two common backlogs
Release backlog: The stories needed for the
next complete release
Iteration backlog: The stories chosen
for the current iteration
Common Backlog Problems
The release backlog is a very long list of every possible story.
Hard to prioritize and estimate
Demoralizing to developers
Each iteration backlog is just a collection of unrelated things to do.
Few if any big victories.
Scenario Backlogs
A prioritized backlog of scenarios or demos.
Each scenario is a real story, where a specific user
achieves a specific goal from start to finish.
Under each scenario, list the user stories that need to be implemented or extended to do the scenario.
Example possible scenario backlog
Scenario backlog goals
Backlogs are shorter, all stories have a purpose.
A scenario completes delivery of value, not a single step
A scenario is an acceptance test.
Demos tell a convincing story.
Only show features that fit a realistic story, e.g.,
Apple's demo of the first WYSIWYG editor was about making
a one-page flyer -- type and edit text, change fonts, insert picture, no more.
Develop incrementally
Write minimum viable scenarios.
Each scenario demonstrates one piece of user value.
Write simplest user stories that will make scenario work.
<More to come!>
Thanks to Hakim El Hattab for RevealJS
Resume presentation
Scenarios and Stories
Managing the Backlog