Best ways to fit bug fixing into a Scrum process? [closed]

Question

I have been studying and reading about Scrum in the last few days and reading about Sprint Planning and tasks. One problem that popped into my mind is how to deal with bugs in Scrum. Henrik Kniberg lists some ways of dealing with this issue in his very nice book Scrum and XP from the Trenches :

1. Product owner prints out the most high priority Jira items, brings them to the sprint planning meeting, and puts them up on the wall together with the other stories (thereby implicitly specifying the priority of these items compared to the other stories).
2. Product owner creates stories that refer to Jira items. For example “Fix the most critical back office reporting bugs, Jira-124, Jira- 126, and Jira-180”.
3. Bug-fixing is considered to be outside of the sprint, i.e. the team keeps a low enough focus factor (for example 50%) to ensure that they have time to fix bugs. It is then simply assumed that the team will spend a certain amount of time each sprint fixing Jira- reported bugs
4. Put the product backlog in Jira (i.e. ditch Excel). Treat bugs just like any other story.

Is this really something that needs to be decided per-project basis or are there better solutions? I can think of problems with each of those approaches. Is there a hybrid coming from those approaches that works best? How do you handle this in your projects?

Pharmacognosy

You may wish to distinguish between different classes of bugs: for high-priority bugs you can't even wait for the next sprint, so it kind of imposes itself anyway. – Imena

When the bug is in an Story that is under development in the current sprint, it is fixed straight away. When not in an existing Story, then a new story should be created to cover the correct behaviour and added to the backlog, unless the item is Blocker or Impediment to current story. – Ester

I'm voting to close this question as off-topic because it belongs on pm.stackexchange.com – Brawny

Answer 1

This is a very good question and I have some observations when it comes to different approaches to this problem.

1. Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
2. Explicit time in each sprint reserved for fixes is fine if done in a way that is visible for the product owner. Bugs should be mentioned during the daily scrum and discussion about bugs fixed should occur during the sprint review. Otherwise the product owner won't be aware of what's going on in the project.
3. Putting the whole backlog in bug tracking tool leads to the same set of problems as in 1. Moreover most bug trackers are not designed with Scrum in mind and using them for this purpose can be painful.

The solution we found the most satisfying was to put a single user story called "Tickets" or "Bugs" on every sprint. Then such a story can be divided either into low-level tasks describing a particular bug (if known during planning) or meta-tasks reserving a given number of hours for general bug fixing. This way the product owner has visibility into the process and the burndown chart reflects the progress.

Just remember to mercilessly close all "bugs" that are actually new features and create new backlog items for them. Also make sure to fix all the bugs reported against the current sprint before the sprint is over in order to consider the sprint as done.

Contredanse

My team follows a similar solution. – Appellative

YouTrack covers #3. It's not as painful as it seems as long as the bugs are properly triaged into the proper category as you described. – Knott

Answer 2

Actually I think that best is answer by jpeacock from this question Do you count the hours spent on bug fixes towards the scrum?

Let me cite it:

• If the bug is easy/quick to fix (one liner, etc), then just fix it.
• If the bug is not trivial, and not a blocker, then add it to the backlog.
• If the bug is a blocker then add a task (to the current sprint) to capture the work required to fix it, and start working on it. This requires that something else be moved (from the current sprint) to the backlog to account for the new hours because your total hours available hasn't changed.

Rollo

Answer 3

The first step is to define what a bug is. I teach that a bug is only a bug if it is functionality that does not work in production as it was intended/designed. These become bug type PBIs to be prioritized against new development. Missing functionality in production is a Feature and becomes a normal product backlog item. Any defective code found during a sprint is considered incomplete work and since you don't move on to the next story until the current one is done-done; it is unnecessary to track these defects in the sprint as the team is always working on the offending code. Post-its can be super handy here for quick reminders between team-mates. Fixing broken code always takes precedent over writing new code. If the defects are due to misunderstanding the story then you need to work on your conditions of acceptance before starting the story.

Inventory is waste. Bug tracking is inventory. Bug tracking is waste.

Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.

If you have that many more bugs than features then you need to work on your engineering practices. This is a smell that something else is wrong and tracking is not the answer. Dig deeper. Actually bugs are always smelly. They aren't cool and if you have lots of them you need to find the root causes(s), eliminate those, and stop focusing on tracking bugs.

Reta

+1 for a good definition. In my experience, there is almost always "bugs", but I find that most of the time, writing new features is something that management wants over trivial bugs. How would you recommend dealing with management or another dev that does not feel the same? – Nurseryman

Answer 4

Don't track defects on a list, find them and fix them -- Mary Poppendieck

Indeed, If inventory is waste, what about an inventory of defects...

That's why I always try to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list.

And when defects pass through, we fix them before writing new code (stories with bugs aren't done anyway). Then, we try to fix our process to make it more mistake-proof and detect defects the moment they occur.

Demagoguery

+1.I like the statement stories with bugs aren't done anyway. So when you find a bug in production that is not new(been there for over an year), do you assign a dev that bug and make it the highest priority? – Nurseryman

Answer 5

There is no one size fits all solution and each project is different. Bugs might also be categorized from mission critical to hardly worth fixing.

Unless critical to the running of the system, I prefer bugs to become story cards. That makes the priority of feature development vs. bug fixing really explicit. In a scenario where bug fixes are considered to be "outside of the sprint" the bug fixing might move toward fixing really trivial bugs while really important business features aren't being developed.

We've gone trough a number of permutations before setting on the bug as a story approach. Try some different things and replay them at team retro meetings.

Noto

Answer 6

In our case (greenfield development, 2-3 devs) found bugs are written down, marked clearly as a bug and based on their severity they are assigned to next iteration or left in the backlog. In case of critical and urgent bugs they are added to the ongoing iteration.

Wolter

Answer 7

I don't know why something as simple as fixing bugs is complicated with rules.. Scrum has very few rules, remember? Every feature, Support, Recommendation or Defect is a Backlog issue in Scrum, there is no differentiation. So, as the Scrum guide says: the tasks in a Sprint are never limited to what you decide during the planning meeting the Daily Scrum helps people discuss "impediments" along their way.

Why?

So you discuss and think rationally as a team if you want the defect i.e. backlog issue to go into PBI or remain in this Sprint and deliver it...

Aprilette

Answer 8

Better question is how do I stop creating bugs in development phase? see--> http://bit.ly/UoTa4n

If you are identifying and documenting bugs you will have to triage and fix then at some future time. This leads to "stabilisation sprints" i.e. one whole sprint just to fix bugs. Or you can add them back to the backlog and prioritise them as part of some future sprint. It also means that you will are providing and expect to get signed off and released software with known bugs in it (P3 & P4 aka cosmetic and minor).

This is not really agile?

Bra

The link is broken. – Maleeny

Answer 9

I have tabled the idea in our project to introduce a short bug fix sprint every third sprint. Our current sprints are three weeks.

The idea is that it will allow all dev to focus on bug fixing together, allow focus on just new stories in regular sprints and keeps a regular focus on reducing tech debt.

Bug fixes will be grouped into relevant stories and prioritised. Emphasis is not on sizing before the sprint as devs struggle to size bug fixes without getting stuck in to understand the nature of the defect.

Has anyone tried this or have any feedback on how they think this might work?

Cheers, Kevin.

Scapolite