[ACCEPTED]-Best ways to fit bug fixing into a Scrum process?-scrum

This is a very good question and I have 18 some observations when it comes to different 17 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 16 we found the most satisfying was to put 15 a single user story called "Tickets" or 14 "Bugs" on every sprint. Then such a story 13 can be divided either into low-level tasks 12 describing a particular bug (if known during 11 planning) or meta-tasks reserving a given 10 number of hours for general bug fixing. This 9 way the product owner has visibility into 8 the process and the burndown chart reflects 7 the progress.

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

Actually I think that best is answer by 1 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Why?

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

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

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

This is not really agile?

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

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

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

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

Cheers, Kevin.