Bugs & Scrum
Bugs, those pesky errors that you didn’t foresee.
As defined by Wikipedia, a bug is:
… an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Scrum, the process we all know and (some) love.
As defined by the the creators, Scrum is:
… a simple framework for effective team collaboration on complex software projects.
What isn’t so well defined is when and how to document a bug whilst working in Scrum.
Most people will agree that bugs should be documented somewhere; the simplest being on a piece of paper, the more advanced being in an issue management system such as Bugzilla or JIRA.
Should you then document every bug you find during a sprint? I don’t think so, in fact I think doing so can be detrimental to your team.
Let’s look at the definition of a bug again, focusing on one key part:
… an error … that causes [a system] to produce an … unexpected result …
Whilst in a sprint, until a user story is marked as done, everything is inherently still work in progress. Therefore, having an error in the system isn’t unexpected, it’s an integral part of the iterative, day-to-day, improvement of the sprint backlog.
If you were to document each occurrence of a bug found during a sprint you’d end up creating a massive overhead for the rest of the team. Each bug would have to be reviewed, updated, and marked as finished.
Looking at the definition of scrum again we can imagine how that might be detrimental to:
… effective team collaboration …
My preference is to fix the bug immediately. If you find a bug in someone else’s code then just go show them, or better yet create a patch fixing the bug and have them review it.
Sometimes fixing a bug immediately is not feasible. Perhaps you found it 5 minutes before the sprint demo, you are about to go home and plan to fix it in the morning, or it’s such a minor bug that you think you can release the sprint with it.
In these cases you should document the bug and have it prioritised at the top of the backlog.
Documenting a bug for these reasons is more about not forgetting about it rather than officially logging an error in the system.
There are instances, however, when you should document a bug, no matter when you are going to fix it.
If the bug relates to a user story that the team considered to be done i.e. from a previous sprint, then documenting it is required.
This allows the team to decide when to fix it, in this sprint or perhaps the next.
Documenting bugs in this way can be used as input to the sprint review. The team can clearly see if there is a trend of improving or regressing quality. If they find that in every sprint they find bugs from the last, they can start looking at their definition of done and see what’s missing. Perhaps they aren’t writing enough functional tests or their code reviews aren’t being taken seriously.
It is useful to make the distinction between a bug that was documented so as to not forget about it, and a bug that was found after the work was considered done.
To facilitate this my recommendation is to have some metadata that records this e.g. a ‘found in’ or ‘affects version’ field.
Allowing the freedom to make mistakes during a sprint is vital.
If you start documenting every occurrence of a bug then people tend to start siloing themselves; trying to hide their work from the rest of the team until they think it’s perfect.
This is obviously not congruent with the ideals of open, frequent, and honest communication required for a successful Scrum team.