How to Write User Stories for Bugs

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask

I was finishing up a week of training with one of my clients, and by all accounts, it was a stellar week.  People were excited and motivated to jump head first into Scrum, and the product owners were excited to start writing stories.  One of the tech leads came up to me and said, “What about bugs?” “What do you mean?” “I mean, do we write user stories for bugs?” “If you want to.  Its not absolutely necessary, but if you have 10 minutes we can chat about it.”

shutterstock_218921119

Should a team write user stories for bugs?  You should do this only if expressing the bugs in user story form has value. User stories are useful but not always necessary.

On Defect Management

Defect management is one of the areas where companies tend to trip over themselves trying to figure out “How agile says we should do it.”  Take a step back from the process and look at the goal.  The goal is to deliver working software that fulfills customer needs.  In a lot of cases, administrivia is a non value add but necessary component of delivery.  We want to minimize this where we can, and when we can’t minimize it, ensure that it has value.

So instead of asking, “Should we write bugs as user stories”, ask yourself, “Would writing bugs as user stories add any value to us delivering software to our customers.”

When you frame this question, and a lot of other questions in this manner, the answer becomes obvious.  Even if you pick the wrong answer, you can always retrospect and change it.

Bugs as User Stories

So in this article I will show you how to write user stories for bugs, should you decide to go that route.

Each bug report should be considered its own story, especially if fixing the bug is likely to take as long as a typical story (2 days or so).  For bugs that are minor and can be fixed quickly, these can be combined into a single bug story.

Step 1.  Use “Without” in your user story description

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.  What this does is outline the behavior you DON’T want (the bug) from the perspective of its impact on the user.

Step 2. Outline “Steps to reproduce” in your story details

This reiterates the conditions that will help the developer understand how to create the bug and helps with testing.

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.  What this does is outline the behavior you DON’T want (the bug) from the perspective of its impact on the user.

  • Using android or iPhone, log into the admin panel
  • Expected result:  responsive panel
  • Actual result:  squished panel (unusable)

Step 3.  Invert story description in your acceptance criteria

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.

  • Using android or iPhone, log into the admin panel
  • Expected result:  responsive panel
  • Actual result:  squished panel (unusable)

Acceptance Criteria

  • User can log into the admin panel on a mobile device and it will be usable
  • The admin panel will accommodate various screen sizes
  • Report viewing will be disabled on mobile, but the user has the option to send a pdf to their email

A view from the field

Some teams like to write their bugs as user stories, and others don’t.  Like nearly everything, it depends on context, environment, industry, company size, and a lot of other variables.  What about with your teams?  Do you write stories for bugs?

There was an issue loading your timed LeadBox™. Please check plugin settings.