Wednesday, November 2, 2011

The Given, When, Then - User Story Scenarios

In a previous post I talked about User Stories. This post is the next step on from there, and a way to evolve the User Stories into Scenarios.
As useful as this stuff is, it is often not used.

The relation between Stories and Scenarios 
A User Story will contain one or more Scenarios and the Scenario describes how the Story is used.

The Scenario Recipe
These are the three ingredients to writing a Scenario:
  1. Given a context and set of circumstances
  2. When something happens
  3. Then the outcome is
Given <one or more contexts here> when <something is done> 
then <the outcomes go here>

Some examples
The following examples start from a User Story, which is where they should start of course.

User Story: Refund on a wheel
As a customer I want return a purchased wheel so that I can get a refund.

Scenario #1
Given I am a Platinum user and I have purchased a new wheel, when I wish to return the wheel within 30 days of purchase, then I can do so without a penally.

Scenario #2
Given I am not a Platinum user and I have purchased a new wheel, when I wish to return the wheel within 30 days of purchase, then I can do so without 75% penally.

Scenario #3
Given I am a Platinum user and I have purchased a new wheel, when I wish to return the wheel after 30 days of purchase, then I can do so with a 75% penally.

Scenario #4
Given that I am a customer who has returned a wheel, when I am given a refund, then I get a notification email.

User Story: Order an out of stock item 
As a customer I want to be informed on the status of out-of-stock items so that I can cancel the order if it takes too long.

Scenario #1
Given that I have ordered an out of stock item, and I have been told the wheel's delivery is 2 weeks, when the wheel is not in stock on despatch day - 1, Then email me and apologise and offer to cancel the order.


So why bother
There is a lot more information in these Scenarios and the process of getting people together and talking about these is hugely productive. You do not need a highly paid analyst or a developer guru for this stuff. You just need to start thinking, talking and recording. If it's incomplete and your project environment is evolving, then just starting is a great step forward.

What you can do, is pick a fictitious project, a small project, and go through the motions. This will be quite instructive.

In an earlier post I mentioned the INVEST acronym which stands for Independent, Negotiable, Valuable, Estimable, Sized, and Testable. This technique of writing Scenarios enables Testing and it go somewhere to assist Estimating.

I think the next post should be about using these User Stories and estimating work. I might wait for a week or so.

No comments:

Post a Comment