Definition of Done for User Stories vs. Bugs

19 Dec, 2008
Xebia Background Header Wave

One of the most important concepts in Scrum is the Definition of Done. With it,the Scrum team and stakeholders determine what exactly is needed to finish a user story. Typically it includes one or more of code complete, developer tested, documented and acceptance tested.
In my current project, the system we are building has been accepted by the client and is in production. At the same time, however, new development on the software is taking place. The bugs and user stories resulting from the first and second activity end up on the same product backlog and are worked on by the same Scrum team. For the user stories, we include coding, development testing and documentation in the Definition of Done. This has worked well for us and allowed us to create the system in the first place.
However, the bugs are a different story. These are defects in the already existing software that were found by either an external testing team or in production. At first, we were using the same Definition of Done for the bugs as for the user stories. When delivering software fixes for these bugs, our customer would regularly ask us a series of
questions we had no answers for:

  • which versions/applications are impacted by this bug?
  • which versions need to be patched?
  • does this affect the interface between applications A and B?
  • is there a workaround for it? Has it been documented?

We realized the Definition of Done for the bugs needs to be different from the ones used for regular user stories. By including the questions above, we create transparency about what we need to consider when solving bugs and are able to better meet the customer’s expectations.
What do you think? Is it a good idea to use different DoDs for user stories in one backlog?


Get in touch with us to learn more about the subject and related solutions

Explore related posts