How to manage bugs in an Iteration?

I think it's useful to make a distinction between bugs in newly done work during the iteration (for example, introduced during the design and implementation of a Product Backlog Item selected for the Sprint) and bugs discovered in a delivered Increment that need triage and perhaps resolution.

I tend to look at defects injected during the implementation of a Product Backlog Item as unfinished work. The ideal situation is to resolve all known issues prior to the delivery of the Product Backlog Item. However, in practice, there may need to be decisions about reverting work to remove defects or delivering the product with known issues because the impact of the defect is low enough that getting real-world feedback is more valuable. The Product Owner, as the individual accountable for maximizing the value of the product and as the voice of the stakeholders on the Scrum Team, is in the position to help the team make the best decisions on how to proceed if defects are found prior to delivery.

In cases where a product Increment will be delivered with known issues, putting this work onto the Product Backlog is a good idea. Any other kind of traceability would depend on the team's way of working, the tools that they use, and the environment in which they are working. However, I would tend to mark the initial representation of the work however the team denotes done and delivered work.

To the extent possible, defects detected in delivered product Increments should be triaged and placed on the Product Backlog, ordered among all of the other work to improve the product. Some defects, however, may be so impactful that they require immediate attention. The Product Owner should be able to approach the Developers at any point with this type of issue and come to an understanding about what would be necessary to fix the defect and the impact that it would have on the Sprint Goal and the ability to deliver the other Product Backlog Items selected at the Sprint. The Product Owner is in a good position to represent the stakeholders and determine if achieving the Sprint Goal or delivering the selected Product Backlog Items is more valuable than taking on the new defect. Although the Sprint Backlog is entirely managed by the Developers, I'd hope that a team of professionals would consider the needs of stakeholders, as expressed through the Product Owner, and make decisions that support their needs.

Although I'm not personally a fan of estimating Product Backlog Items, if the team is practicing estimation, I would estimate anything that is put onto the Product Backlog. This would include both deferred known issues as well as newly discovered defects. I'd also consider estimating work that is brought into the Sprint for consideration in terms of the team's capacity for doing work. However, I would not estimate issues found when testing newly developed Product Backlog Items and fixed in-Sprint, since the estimate of the original Product Backlog Item should include the necessary testing and defect resolution.

How are bugs managed within an Iteration?

I'd suggest that each one of the "bugs" you describe is either:

• New work discovered this Sprint which remains for the Increment to be Done, or
• Technical debt previously incurred, and which ought to be remediated.

What might that imply about the best way to manage them?

I prefer to think of bugs as "items that need to be done in order to provide value to the product".  I don't advocate distinguishing bugs from stories.  In fact, I advocate that there is no such thing as either, just Product Backlog Items that are all treated equally. 

If during the timebox of a Sprint, something is determined to provide negative value to the product, I advocate that it be analyzed to determine if it is required to be addressed in order to meet the Sprint Goal. 

1. If so, do the work as part of the work involved with doing whatever you were doing when it was discovered.  If the Sprint Goal is in no danger because of this new found information, discussion ensues about whether it can be addressed without harming the possibility of meeting the Sprint Goal.  If the information can be addressed in the current Sprint Timebox, I see no real reason to write it up unless there needs to be some record of it per organizational rules.
2. If the Developers do not feel that they can address it and still meet the Sprint Goal, an item is written up and put on the Product Backlog.  

Since I see everything individually, I am able to avoid the dilemma of having an item "incomplete" because there is still work to be done.  If that is to be the case, refer to my first solution.

I'd suggest that each one of the "bugs" you describe is either:

• New work discovered this Sprint which remains for the Increment to be Done, or
• Technical debt previously incurred, and which ought to be remediated.

What might that imply about the best way to manage them?

Agreed on this, I'm trying to figure out the best way to manage this, perhaps I should put it in a different way.

1) Should bugs be recorded? Things to consider is whether this data can be used for some quality measures, whether the developer and tester is the same individual or separate individuals, is this a bug that can be fixed by this team or an external team? Can the bug be addressed in the current Iteration? Is the bug from previous features or relating to the features are developed during this Iteration? If the bug needs some prioritsation by the Product Owner?

2) Sould bugs be estimated and count towards the teams velocity? If the bugs aren't estimated and counted then the team velocity will decrease as more bugs are found and increase when less bugs are found. Probably a good thing IMO as the goal for the team is to increase team velocity and have less bugs. However, if it is not estimated then it maybe difficult to see how much work the team is able to commit to for the next Itertaion for example where there maybe a decision to take on work to fix 3 bugs and 5 new features. Perhaps the answer maybe to estimate bug fixes that are in the Product Backlog for planning purposes but not count towards the teams velocity? Hence in this case they will be commiting to less work for the next Iteration than what is advertised as their capacity however, the story points for the User story from the previous Iterations will be counted in the Iteration where the bug is fixed.

3) How to manage bugs from external teams? I think a bug should be raised for this so that it can be tracked and prioritised. Let's say the team has completed 90% of the work required for one User Story and the other 10% is blocked by a bug from an external team and they can't fix it during the current Iteration and hence, the User story can't be moved to the DONE state and that 90% of the completed work isn't counted in the team's velocity.

You seem to be fixated on velocity and you measure that by how many items in your Sprint Backlog reach completion.  If you look at Merriam-Webster's definitions of velocity none of the them say anything about completing something. They are about how quickly something moves.  In Scrum, the thing to measure is how quickly work is moving so that value is delivered on a consistent basis.  The goal of a Sprint is to satisfy the Sprint Goal, not to complete all of the items in the Sprint Backlog.

I recommend that you stop focusing on the percentages of work done and instead focus on the delivery of value.  How long does it take to deliver something of value to the stakeholders on a consistent basis? 

You might also want to help the team focus more on their refinement activities to better identify these dependencies on external teams before they become an impediment. 

Another thing the team might want to focus on is why they keep producing software defects.  Are they rushing and being sloppy?  Should portions of the code be refactored?  Instead of focusing on how to deal with bugs when they are found, focus on not creating bugs in the first place.  

How you do any of this is up to your Scrum Team to decide.  They are a self-managing, self-organized group of individuals that are allowed the freedom to work in any way that they feel is best.  If the team can't decide on one thing, help them agree to try something for a Sprint or two.  Experiment and apply empiricism to the process.  Do something, inspect what happens, learn from it, adapt as necessary.

Don't try to find a solution for how to handle bugs. Use each bug found as an opportunity to inspect and adapt so that the current problem does not repeat itself. 

You are probably right, I maybe putting too much emphasis on team velocity.

In Scrum, sprint goals cannot be compromised. Therefore, when a high-priority bug or defect emerges, your developers might ignore it if addressing it will compromise the sprint goal. To maintain Scrum, assigning 5 to 10% of your sprint backlog to unanticipated issues and defects is a good practice. Therefore, your sprint goal would ensure that the already accomplished increment shall be preserved free of critical bugs.

Would I be correct in considering a bug to still be an item of value? It's a negative value, but still a value measurement. And two main considerations with bugs that are slightly different from user stories or features: Risk (how likely) and impact (hiw much it may hurt). Both of those would have to be taken into consideration to determine a relative value for the bug compared to the rest of the backlog right?

Would I be correct in considering a bug to still be an item of value?

In my opinion you would be absolutely correct.  Every bug is negative value as long as it is exists and positive when it is removed.  Every feature has negative value as long as it is still needed and positive when it is delivered.

Now consider the value of items in the Product Backlog.  There are also 2 values.  Negative as long as it exists in the backlog in a To-do state and positive when it exists in a Done state.  

 Risk (how likely) and impact (hiw much it may hurt). 

Both of those apply to features as well.  For example, risk is a factor of not delivering it or delivering it too late.  Impact is a factor of delivering it too late or at a specific time in which changes would have negative impact on the consumer (think major UI changes to a retail application during Holiday shopping season). 

Every item that describes work that is needed to be done to a product has two values. And each one has a unique set of criteria that can be applied when determining relative value. 

Would I be correct in considering a bug to still be an item of value? It's a negative value, but still a value measurement.

My advice would be to think of it as an item of negative quality which will adversely impact the delivery of value.