The management of bugs in scrum is often a delicate issue in the world of agility. Here is a list of tips that I propose that have already proven their effectiveness.
As I am regularly asked on this topic, I decided to do a little article on the subject. How to handle bugs in scrum?
The bug discovered during the tests
When we are during sprint and the Product Owner tests an US, he may discover a bug on one request; he will refuse to put the request in “Done”. We remind you that the Product Owner will only test the US when all technical subtasks (small blue post’it) are completed (from line 1 of the picture to line 2).
In this case, he will add a subtask bug (small red post’it on the 2nd line) to notify the team of the bug to correct.
!Warning! : we consider in bug only an abnormal behavior compared to the description of the user-story (US). All request of change not present in the US will not be considered like a bug ; the product owner will create a new user-story for a next sprint.
When all the subtasks bugs go into the test column then the Product Owner will be able to repeat a test step on the US in order to validate or invalidate it.
Good practice to handle the bug
When it’s possible, here is the better way to fixe the bug :
- the product owner (or tester) explain the bug at the developer
- they fix the bug together (when the bug is not to long to fix)
- the developer delivers the bug in the stable environment
- they verify that the bug is fixed
The bug discovered later
How do you handle it?
Unfortunately, despite many tests or even regression, it’s essential to support new bugs. In this case, we will add a bug task that should be handle if possible during the next sprints (except for absolute urgency).
In this case, the Product Owner will add a Bug task that will be treated in the same way as a US (or technical task).
You will understand that the bug is not handled in the same way when it’s discovered during tests or when it’s seen in production.
The concept of Impediment
When a bug is urgent (site that does not work anymore, payment out of order), it’s impossible to wait the next sprints to handle the bug.
We will add this bug in the Sprint Backlog in addition to others. We will name this type of task “Impediment” that we will count if necessary to show at the end of Sprint that everything has not gone as planned.
It’s pretty sad but I’ve seen teams count between 30 and 50% Impediment by Sprint; to say that it made Scrum inefficient.
So I like to represent it on the post’it so that it’s visible as you can see below with this post’it with the mention [IM] to declare the request in Impediment:
We will not remove the story point on this type of requests from the Burndown Chart (because not planned at the beginning of Sprint) but we will record it at the end of the sprint to make the predictability if you need it.
We make a RUN team
When we have too much Impediment, we can consider to get two people out of the Scrum team (if it’s big enough) to work on a kanban that aims to handle all the bugs encountered; this technique is also very useful when the company has to handle legacy.
Specificity of this RUN team:
- it participates in Scrum ceremonies
- and it changes with each sprint (to avoid to have people attributed to the bug at 100%)
- it works in continuous flow (kanban)
The Product Owner can even take advantage of this team to make small requests that are important for the company. He prioritizes the request that can be addressed by this RUN team.
Predictability of these bugs?
I advise you to ask your developers to estimate these bugs intervened in production in order to have a better predictability of your sprints.
Indeed, we must take the story point of the bugs into account because this is essential to better manage your predictability. Don’t make the mistake to let the bugs without estimate.
A bug has no business value because it’s a spotted anomaly that should not exist in the product. We will put a business value of 0 for each bug encountered.
A bit of Extreme Programming in this world of Scrum
For smart guys, indeed the US is already an element of Extreme Programming. But now, I will talk you about the concept that says that every bug encountered must give an additional development to be detected automatically the next time.
I really like this idea because it reinforces the quality of the product. This involves adding technical sub-tasks to add this technical test which will detect that the bug does not happen again.
Conclusion bugs in scrum
You know everything about bug management in scrum. Feel free to share your comments with other visitors to this blog.
Be the first to comment