Bugs should be prioritized and fixed immediately by the developer originally working on the topic. Bugs should be estimated along with the product backlog item and fixed within the same sprint. If not all bugs for a PBI are fixed, the PBI is not complete and does not count toward velocity. Late bugs found after implementation are new product backlog items. Teams should inspect and adapt their bug fixing process based on experience.

1. Agile
Bug-Fixing
Priority! Backlog! Estimate!
Should Bugs be added to the Backlog? Should Bugs be estimated? Should all Bugs get
fixed in the last Sprint? Should each Sprint contain a time box for Bug Fixing?
This best practice is based on my experience, which I gained with scaled and distributed
teams. It is tailored to situations which are so complex that processes and tools are
required and cannot be fully substituted by individuals and interactions.

2. Essentials
1. At the end of a Sprint, any new Increment must be
“Done,” which means it must be in useable
condition and meet the Scrum Team’s definition of
“Done” [Scrum Guide and 7th Agile Principle].
That means it needs to be free of Bugs before it
counts towards velocity.
2. The Product Backlog lists all features, functions,
requirements, enhancements, and fixes that
constitute the changes to be made to the product
in future releases [Scrum Guide].
2016-06-11Armin M. Hoffmann 2

3. Fix Bugs immediately
3. Bugs are fixed by the developer who was working on the topic before.
There is no separate bug fixing team.
Only this will promote ownership for working software and ensure that
Bugs can be fixed by a knowledgeable Team Member.
4. Bug Fixing always has priority over additional Product Backlog Items
(PBIs / User Stories).
Only with this approach the most valuable software gets "Done"
[1st Agile Principle] and Technical Debt is avoided [9th Agile Principle].
5. Bugs caused by a PBI should be fixed in the same Sprint as that PBI
is worked on. The Team is responsible for avoiding too much carry
over into the next Sprint.
6. Bug Fixing is included in the upfront effort estimate of each PBI.
This ensures that only those PBIs that actually can be delivered
as working software (Definition of "Done") are selected for a Sprint.
2016-06-11Armin M. Hoffmann 3

4. PBIs need to be “Done”
7. At the end of the Sprint the Product Owner decides if a PBI is "Done" based on the
Acceptance Criteria.
8. As an exception, if the product is potentially shippable, he even can accept a PBI,
if not all Bugs related to this PBI are fixed. Then these Bugs are converted into
new PBIs and the original PBI is "Done". In this exceptional case the original and
the new PBI count towards velocity. The Product Owner is responsible for avoiding
such low priority functions to be part of the original PBI.
9. In all other cases if not all Bugs were fixed during the Sprint, the PBI is not "Done"
and does not count towards velocity. Then the PBI is moved back to the Backlog
and is handled as any other PBI, but usually will get selected again for the next
Sprint.
The remaining effort for Bug Fixing is estimated in the same way as any other PBI
would be, because Bug Fixing reduces Sprint capacity. As always estimates don’t
need to be 100% accurate. If absolutely necessary, an investigation (Bug Spike as
part of the original PBI) may be conducted first to gather enough information. As
for any other development work, the effort is not time boxed to the estimate,
because the priority remains on delivering the most valuable items first.
2016-06-11Armin M. Hoffmann 4

5. Fix remaining Bugs early
10. If efforts for Bug Fixing reach the Sprint capacity, no new PBI can be
selected into the Sprint, resulting in a pure Bug Fixing Sprint. The
Team is responsible for avoiding so many Bugs.
11. Bug Fixing should be accomplished at the beginning of the Sprint.
There are many advantages: the original PBI is still known; the whole
Team can focus and collaborate on bug fixing to start new PBIs
based on a clean code base; and they can be re-tested
independently of new PBIs.
12. As soon as all Bugs of a PBI are fixed, the PBI is "Done" and counts
with its original estimate towards velocity. But the Bug Fixing efforts
(although estimated) do not count towards velocity.
Bug Fixing itself is waste (idle work), it does not earn business value,
only the original PBI does. Because working software is the primary
measure of progress, not the accomplished work.
2016-06-11Armin M. Hoffmann 5

6. Late Bugs are new PBIs
13.There also may be the case, that a Bug is only
discovered long time after implementation (e.g.
in Production). Fixing such a Bug is captured
as a new PBI that is prioritized by the Product
Owner and handled in the same way as any
other PBI.
If the Product Owner wants to stay flexible to
resolve Issues and Bugs from Productions
instantaneously (during the Sprint), he could
advice the Team to reduce the Sprint forecast
(capacity based on the velocity) accordingly.
2016-06-11Armin M. Hoffmann 6

7. Empiricism
14.As Scrum is based on experience and making
decisions based on what is known, each team
must inspect and adapt these procedures
during Sprint Review and Retrospective.
2016-06-11Armin M. Hoffmann 7
So I only have my teams to start with this approach. After a few Sprints experience
they then can modify the approach to meet their specific situation.