Skip to main content

How to manage bugs in an Iteration?

Last post 02:38 pm November 3, 2022 by Ian Mitchell
10 replies
11:58 am April 27, 2022

How are bugs managed within an Iteration? Here are some of my thoughts, all suggestions and discussions are welcomed! What are some common practices?


For example, we found the below 5 bugs while working in this Iteration. Any other type of Bugs that maybe up?


Bug#1 is due to unclear requirements

Suggestion: Create a new user story in the backlog and prioritised by the product owner.


Bug#2 is due to a bug found while coding a feature relating to a user story the team is working on in this Iteration

Suggestion: Bug to be classified as High/Medium/Low and aim to be fixed in this Iteration, if not then see further information below when we reach the end of the Iteration.


Bug#3 is due to a bug found from a previous features which was undetected previously

Suggestion: Same as Bug#2


Bug#4 is due to a bug found from the code that was developed by another team or external vendor

Suggestion: Same as Bug#2, however, if it is not fixed within this Iteration then how do we manage the User Story that can't be closed and the teams velocity? Doesn't make sense to penalise the team if it was not due to an error by them. Can the user story and story points be split?


Bug#5 is due to a bug found in production which needs to be fixed

Suggestion: Product owner to decide whether it needs to be fixed in this Iteration or prioritised in the backlog to be fixed for future Iterations.



Also, what do you do with the User Story with an open bug at the end of the Iteration?

Suggestion: If the bug is classified as a high priority bug and it doesn't meet the definition of done criteria then the user story remains open until it is resolved. What do you do in this instance if the bug is related to code that has been developed by another team? If the bug is classified as a medium priority which means it has a acceptable workaround then the user story can be closed and a user story is created in the product backlog and prioritised by the product owner to be worked on a future sprint. If the bug is classified as a low, i.e. cosmetic and not to be fixed and accepted by the product owner then the bug and user story is closed with no further action.


Finally, do you estimate and count story points for bugs?

Suggestion: If it is an internal bug then no which means the velocity of the team will decrease as the no. of bugs increases, If it is an external bug then yes, as the teams velocity should not be penalised as a result of external factors. The issue I can see with this appoach is that the team may have a tendency to first blame an external party when it is not clear who is responsible for the bug and also it does take some time to figure out who is responsible for the bug.

07:21 pm April 27, 2022

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.

08:02 pm April 27, 2022

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?


08:20 pm April 27, 2022

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.


11:05 pm April 27, 2022

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.

02:46 pm April 28, 2022

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. 

03:15 am April 29, 2022

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

08:01 am November 2, 2022

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.

01:19 pm November 3, 2022

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?

02:19 pm November 3, 2022

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. 

02:38 pm November 3, 2022

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.