More than XP. More than one day.

As projects continue, a secret backlog is growing. The items in this backlog never seem to be as cool or interesting as the shiny new features described in the user stories of the product backlog. Where user stories tell us what we want the system to do, this secret backlog tells us all the things the system does, that we don’t want it to do… This secret backlog is our bug-list. This experience report highlights how a bug-list can be a symptom of one or more problems in a team’s approach and how solving those problems didn’t make bugs go away but did make the bug-list redundant.

Implementing user stories feels like progress. Fixing bugs feels stagnant. User stories end up getting all the attention and are prioritised relative to each other whilst bugs become the Cinderella of our product’s requirements - often prioritised only after the next iteration’s user stories have been selected, sometimes even getting relegated to being allocated a rigid, arbitrary percentage of effort for getting them fixed.

When our requirements are in two completely different formats and stored in two completely different places, it’s hard to determine relative priorities when it feels like you are comparing apples and pears.

Ultimately, behind every bug is an acceptance test. Behind every acceptance test is a user story.

There is, however, a key difference between a user-story derived acceptance and an acceptance test reverse engineered from a bug-report. A user-story derived acceptance test often represents an absent behaviour whereas, a bug-derived acceptance test represents a misbehaviour. This misbehaviour can often swing the balance of priorities in favour of removing the misbehaviour rather than implementing a currently absent behaviour. In common user story and acceptance test sentence structures, the fact that they represent an absent behaviour is implicit. With a bug-derived user-story we need to show the misbehaviour explicitly in order to fairly prioritise them.

Objectives Participants will have been introduced to the idea that bugs are merely a source of feedback and can be dealt with in the same way as any other source of feedback that results in a requirement that must be described and prioritised. They should leave the session seeing that a bug report isn’t the conclusion, it is actually the beginning of a story. They will appreciate that, with continued practice, they can reverse engineer acceptance tests from bug-reports and summarise them with constructive user stories. By constructive user stories, I mean the kinds of user stories that most people are used to - stories that describe what we want the system to do, rather than bug-reports telling us what we don’t want it to do. They may also begin to recognise that it is easier to compare customer proposed user stories and bug-derived user stories Some may also begin to see a path to using this approach that, given practice, may result in their bug-tracking system eventually becoming redundant.

They will also be provided with an extension to the popular user-story/acceptance-test sentence structures to ensure that information about ‘misbehaviours’ are available to customers during prioritisation.

A conclusion is something we arrive at when we have decided to stop thinking.

–anonymous