Bug inspired User Stories and Tests

More and more people seem to be keen on this format for user stories:

As a <role>

I want <feature>

So that <benefit>

Attributed to Rachel Davies & Tim Mackinnon - "Tuning XP" - XPDay 2001 And this format for Acceptance Criteria:

Given <some initial context>

When <some action(s) performed/event occurs>

Then <ensure some outcome>

Attributed to Joe Walnes and Dan North in their XPDay 2006 Talk "Awesome Acceptance Testing"

I love these formats, the latter first introduced to me by Rachel Davies. They provide a good framework for focussing customers (and testers') thoughts on what information is required.

Such stories and tests are often based on a product-owner/customer's perceived need. What if you are performing some Exploratory Testing of the application and encounter a user interaction enabled by the development but not handled in the code?...

Most would log it as a bug (that's what it is right?), however, I often find this to be an unnecessary overhead when there is a backlog, user stories and acceptance criteria. Why? Because I often find myself having to translate it into these things anyway... so I figure why not do that immediately and skip adding it to a bug tracking system... instead I add it to the product backlog.

I can't just use the above formats because there is important information missing required to prioritise bug-derived stories and criteria. In the former stories, the interaction and behaviour is often missing altogether. In the case of a 'bug' the interaction is available but the behaviour is as yet unhandled... and infact, can be quite ugly. This is important info for the customer and team leader to address.

For the purposes of the backlog and Acceptance Criteria, I extend these formats with two additonal words

: For User Stories, I add "Rather than":

As a <role>

I want <capability>

So that <business benefit>

Rather than <summary of undesirable behaviour>

Now, the bug isn't a story. The bug should be flipped into an acceptance test and associated with an existing story or one or more acceptance tests summarised by a new story.

And for Acceptance Criteria, I add "Instead of"

Given <some initial context>

When <some action(s) performed/event occurs>

Then <ensure some outcome>

Instead of <description of actual outcome>

Note, this isn't what I do with all bugs. Some are too low level and sometimes all it takes is a quick chat with a developer to get it covered in a unit test or at least as a new technical task. Other times it really is end-to-end... user affecting behaviour. Sometimes I don't know what should happen so I might leave a place-holder in place of the I want and Then statements...

If you are using backlogs, user stories and acceptance criteria, perhaps you might find these paragraph structures useful too.