Scenarios and Stories

• 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.

• As a <type of user> I can <do an action> in order to <achieve a user goal>
  • As a shopper, I can add items to the cart without logging in, in order to track possible purchase
  • As a vendor, I can upload my price list spreadsheet, in order to avoid having to enter data twice.

• 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)
  • Agile Samurai, Chapter 6

• 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

• 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.

• 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

• 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