How to handle bugs in scrum?

bugs in scrum
bugs in scrum

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).

board bug
board bug

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 :

  1. the product owner (or tester) explain the bug at the developer
  2. they fix the bug together (when the bug is not to long to fix)
  3. the developer delivers the bug in the stable environment
  4. 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).


Tâche bug en agile
Bug task in agile

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:


Post'it de User Story
Post’it of User Story

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.

run kanban
run kanban

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.

(Visited 7,923 times, 4 visits today)
About Judicaël Paquet 190 Articles
Judicaël Paquet (agile coach and senior devops) My activities in France and Switzerland: - agile transformation architect - customized agile training - sensitization and manager coaching - agile maturity audits and situations - agile coaching (teams, orga, product owner, scrum master, agile coach) Specialties: scrum, kanban, management 3.0, scalability, lean startup, agile method.

Be the first to comment

Leave a Reply

Your email address will not be published.