Estimating bugs (unplanned items)

We do not commonly estimate bugs. We're doing product development and reserve timeboxes in our Sprints to fix bugs. To be able to estimate a bug we would need to thoroughly investigate why that bug occurs. This produces, in our case, too much waste. That's why we reserve timeboxes and "just fix" as many bugs as we can during that timebox.

> Is it common practice to estimate bugs/unplanned items?
>
> Not talking about findings found during the sprint.

Undone work for the product belongs on the Product Backlog. It doesn't matter whether it is a defect or newly identified scope. Each Product Backlog Item must have an estimate so it can be planned into a Sprint timebox.

+1 for Ian's comment above. As these bugs aren't a result of sprint work they are PBI's in their own right

THanks everyone!

Posted By Ian Mitchell on 17 May 2016 10:56 AM
> Is it common practice to estimate bugs/unplanned items?
>
> Not talking about findings found during the sprint.

Undone work for the product belongs on the Product Backlog. It doesn't matter whether it is a defect or newly identified scope. Each Product Backlog Item must have an estimate so it can be planned into a Sprint timebox.

We made the experience that estimating bugs takes a lot of time (not in all but a lot of cases). When we investigated a bug enough to make a proper estimation, we could have also fixed that bug.

May I ask how do you handle that? Or are your bugs all easily estimatable?

If you view a bug as an additional work (sometimes large PBIs are disguised as bugs), then yes, why not estimate it as a regular PBI.

But more often then not a bug is a resolution of a technical debt, and as such does not bring new business value (it shouldn't exists in the first place), in this case why waste time on estimating something that doesn't bring value? It should just be a part of the velocity, so time-boxing to reduce the waste of additional estimations is actually a good idea.

Mchael,

you can advice the team to use following practice:
- for a bug that is hard to estimate due to missing information, assign it a fixed value (of whatever units are used for estimation) that would set a time-box. Time-box should expire before the next Daily Scrum,
- spend this time-box to do whatever is believed is necessary to fix the bug (and/or uncover missing information),
- share any findings on the next daily at the latest; preferably sooner, if there was any breakthrough,
- if the bug was fixed within a time-box, congratulations! Your team should get some candies :-),
- if the bug wasn't fixed then the team should decide what to do next with regard to Scrum Guide:
1. No changes are made that would endanger the Sprint Goal;
2. Quality goals do not decrease; and,
3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

> We made the experience that estimating bugs
> takes a lot of time (not in all but a lot of
> cases). When we investigated a bug enough to
> make a proper estimation, we could have also fixed that bug.
>
> May I ask how do you handle that? Or are your bugs all easily estimatable?

See the Bradley Bug Chart:

http://www.scrumcrazy.com/One+way+to+handle+Bugs+and+Production+Support…

For the record: The URL of the Bradley Bug Chart has changed:

https://scrumcrazy.wordpress.com/2012/04/18/one-way-to-handle-bugs-and-production-support-in-scrum/

And it has moved once again!  :-)

https://scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/

Updated link as a link this time...

https://scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/

I coach my teams to view bugs in a couple ways.

1. If you find the bug during the sprint as a result of what you are changing and you can not deliver the potentially shippable increment with that bug in existance, fix it now.
2. Same situation as #1 but in this case, the potentially shippable increment can be shipped with the bug in place, create the bug as a story in the backlog and treat it just like everything else in the backlog.
3. If the bug is found in production,  create the bug as a story in the backlog and treat it just like everything else in the backlog.

The stories in the backlog will represent technical debt.  Repairing/eliminating technical debt does provide value to the business. See this article (https://www.scrum.org/resources/blog/managing-technical-debt) by the ever present @Ian Mitchell or this video (https://www.scrum.org/resources/slaying-technical-debt) by Todd Miller.  

Same situation as #1 but in this case, the potentially shippable increment can be shipped with the bug in place, create the bug as a story in the backlog and treat it just like everything else in the backlog.

In my view this doesn't abide by two fundamental values (committment, focus) and knowingly creates waste by allowing extra work (that's basically waste itself) to burden the product and the business, and unnecessarily adding pressure to the backlog and future considerations for sprint planning.

So rather than focusing on code quality, the team is willingly accepting that there is a bug (or more), but they won't fix it as (for whatever reasons) it's not important enough. Whereas, if, upon inspection, a problem is found, it is always most cost-effective to fix it as it's fresh -as soon as it's discovered (and by the same dev coding for the story).

Note this discussion is about bugs, not a minimum viable product where a decision on what is part of MVP and what isn't have no impact on software quality, future sprints impact, technical debt, etc.

In my practice I advise against knowingly and willingly accepting functionalities/increments with known bugs to be put into production (and said bugs added to backlog for future coverage).

I am aware that in some limited circumstances it may be necessary to accept some minor flaws going out, but in my opinion, the rule should be the opposite.

Hi all!

I understand that the best option is working with a single Product Backlog (features, tasks, bugs, ...), but I don't know if the following option is good or viable:

1. The Product Backlog with all the features and tasks that constitute the changes to be made to the product in future releases.

2. Another backlog or kind of priorized list with all the bugs. The priority would take into account several aspects: the severity of the bug, if the bug is in production, if the bug has been reported by the customer, ... DEV Team will fix these bugs by priority order, with no need to previously estimate each bug.

3. When creating the Sprint Backlog do not fill it with the total velocity, leave some margin to dedicate it to bug fixing.

Thank you all in advance for your feedback!

I understand that the best option is working with a single Product Backlog (features, tasks, bugs, ...)

Do you understand why this is best, and is the advice given in the Scrum Guide? What actual advantage do you see in the different approach you suggest?

Hi Ian! Thanks for your fast reply :)

I suppose that one single PB is better because managing a single priorized list is easier than managing two, and "forces" the team to estimate all of it's content (including the bugs). This way, all PBI (features, tasks, bugs) have story points and is easier to decide what to do in every sprint acording to the velocity of the team.

My approach (which I have doubts) comes from these reasons:

1. I understand that some developers think it's not necessary to estimate the bugs, sometimes it can be very difficult to calculate it. And I've read some people who have the same doubt.

2. I have worked in projects with a high volume of improvements and bugs. That means a lot of time to estimate, and the decision was to not estimate bugs. [OK, if there are a lot of bugs this is an issue to be discussed in the Retro, but this is not the point now ;-)]

3. I have worked in projects where the Product Owner made these two lists (1. PB, 2. Bugs) where BUGS were not estimated. I wonder if it's really a problem in Scrum or not, and why.

4. Finally, another question that comes to me now... If the team works with a single PB, if the first PBIs are all bugs, and the velocity can be filled only with bugs, you can create a sprint only with bugs? I understand the answer is NO (although in critical situations with many bugs in production some client asked me to prioritize only errors in a sprint and we didn't do it) so... in this unfortunate case, what percentage of improvements and bugs would be correct? If there is any guideline about it (I suppose the answer is NO, hahaha)

Thanks again!

An item in the Product Backlog represents work that needs to be done to the product in order to deliver value.  The Product Backlog is ordered in a manner to ensure that the Development Team is working on the right items to deliver the value needed at the time.  Keep that in mind as you read the rest of my comment.

Features have 2 values.  Negative as long as it has not been delivered to the end user, positive once the users have access to it and find benefit in it.  Bugs have 2 values.  Negative as long as it exists in the product and causes problems for the users, positive as soon as it is removed from the product and the users are no longer affected. 

Sometimes there is more benefit to removing some high profile, high impact defects from a product than to introduce new functionality.  

So...  why would you want to keep the two types of valuable items in different lists where you have to try and coordinate delivery from both?  Why not put everything into a single list and then order them based upon the value delivered so that the value is maximized for the benefit of the end user?  Could that mean an entire Sprint of bug fixes?  Sure.  But it could also mean an entire Sprint focused on delivering some new functionality. It could also mean a Sprint with a mixture of the two.  Is this against Scrum?  No.  Because Scrum is about delivering consistent value to the end users. 

Thanks Daniel!

"Sometimes there is more benefit to removing some high profile, high impact defects from a product than to introduce new functionality.  " --> Yes it's true

I will continue researching tools and good practices to avoid bugs (DEV, Testing), it was really a problem in projects I worked on (not as Scrum Master).

Hi All,

I have similar query regarding bug estimation for a sprint. 

In case of product backlog contains more number of defects, when these are prioritized for subsequent sprint the following question arises:

1. What is the best approach for estimating the bugs? Hours based or story point based ? Is story pointing possible as there will be known issues and unknown issues as well.  For unknowns, there will be lot of uncertainty in terms of complexity, dependencies, troubleshooting etc.. 

2. How to measure the capacity of the team in case majority of the sprint backlog would consists of bugs only? How can we relate bugs to the velocity?

Please clarify.

My advice is to estimate defects in precisely the same way as all of the other work which is believed to remain. It ought to be refined to "ready" in a similar manner.

Bugs relate to velocity in so far as they reduce transparency over it. The work is not Done, and any measurement taken may simply reflect the rate at which technical debt is being accumulated.

What thoughts do the team have about the Definition of Done in their current situation?

for some reasons that convince me bugs shout not be estimated :

1. Fixing bugs don't bring value, it is ideally a 'broken delivered value'. So FIX IT !!
2. to estimate a bug needs Root cause to be identified, an identified root cause is 50% bug fixed. Estimating a bug by doing RCA technically is a  'Waste' that needs to be eliminated (not always but maximum times). 
3. a story starts with a 'what' (value it brings to the end user), whereas a bugs starts with a 'why' (the value delivered was broken). IMO, if a value delivered is broken, it needs to be fixed right away, based on the severity. PO needs to be in say and control of this task to prioritize bugs for a PBI.
4. a question comes, what if there are too many bugs? This is a question for the retrospective, we must be doing something wrong that so many bugs are raised. We need to identify these gaps - fix them. That is the real BUG.
5. Estimating bugs is like taking for granted that my application is not bug free and I will have bugs to fix every sprint. The aim should rather be to have least possible bugs. Thus estimations are eventually eliminated. How we achieve is by adopting processes to avoid the leaks.
6. Lastly, empiricism doesn't work best with Bugs like stories, because, we know no matter what priority a story carries it is still going to bring value, and hence worth investing efforts in estimation. But for a bug, there could be many immaterial bugs that may take lot of efforts to fix (not complex but time consuming) than a Blocker/Critical issue that may be solved quickly. Investing time in estimating each bug would eventually be waste of time.
7. Hence, bugs could be estimated as a count of issues that we can handle as a team in a given sprint based on historical data in normal circumstances, such that  just enough efforts are invested in fixing bugs which is eventually  less than the efforts invested in implementing stories that bring more value.

Some challenge comments/questions…

1. If fixing a bug improves customer happiness with your product, it provides value. Value comes in many forms.
2. Sizing a bug could include time for root cause analysis. If it is deemed as waste, why wouldn’t it apply to all backlog items?
3. A backlog item could start with ‘why’, ‘what’, ‘when’ or a number of other starters. Agree that bugs are better fixed when introduced/found. If they are however put into the Product Backlog they become product backlog items like everything else in there.
4. Not sure how this ties into sizing or not sizing.
5. Elimination/prevention needs to happen first.
6. Empiricism is about Transparency, Inspection and Adaptation. Why wouldn’t this apply?
7. This could be said of any backlog item. Size is a recommended attribute, not a mandated one. If you use sizing, why not use it consistently with backlog items?

I will start by saying that not all teams are the same. What is good for one may not be good for others.  I have worked with teams that did not estimate defects and others that did.  I have also worked with teams that did not provide any formal estimation for anything.  As Scrum Masters and Scrum professionals, it is not our job to tell the Developers how to work, just to help them find the way that works best for them. 

I would also ask that you provide us your definition of and how you determine "value".  I think it would help us all to better understand your position.

Following @Ryan's lead

1.  
   1. If a feature is delivered and 4 months later the need changes, then wouldn't the original functionality that was delivered be "broken"?  If so, then any work to modify the functionality to fit the current needs would not provide value. So would you introduce work into the Product Backlog to correct the functionality or just say "it's broken, fix it"? 
   2. What if there is a defect that was recently discovered that is causing the application to fail in a critical portion of the code.  For example your eCommerce application will no longer process payments because a third party API has changed and all of your calls are failing.  Would there be value to the end user to have this fixed?  Would there be value to your own organization to have the application fixed in order for your users to be able to use the product? Value can be measured in a lot of ways, not all of them monetarily.
2. Part of identifying a bug is root cause analysis. At least it always has been for me when I was a Quality Assurance Engineer.  In creating a defect report, you have to provide details on how to recreate, what the expected behavior was and what the actual behavior is.  You also provide insights into how the issue is causing problems for the user.  I will also argue that root cause analysis occurs when you are modifying an existing functionality in order to change it. You have to identify if the changes made will cause issue for anything else.  So, how is that root cause analysis is a reason not to estimate a defect but is perfectly acceptable for refining a feature request?
3. There is nothing in the Scrum Guide that states how a Product Backlog Item is to be written.  You are stating some best practices for User Stories which are not mentioned anywhere in the Scrum Guide. I have seen Product Backlog Items that had nothing more than a screen shot with annotations.  A Product Backlog Item should provide enough information for anyone to understand what is being asked or needed.  It is not uncommon for a Product Backlog Item describing a defect to have more information than one that explains new functionality.
4. For this one, see the response I provided on June 22, 2020 in this same thread.
5. You contradict yourself in this statement.  You state "The aim should rather be to have least possible bugs" so you are admitting that there will be some bugs in your product.  Sure, the goal is to have as few as possible but in my 36 years of software development, I have yet work on, use or hear of an application that did not have some defects in them.  In fact, you will never know if that occurs.  A defect is not a defect until it causes an issue. 
6. Empiricism is a philosophical belief that all knowledge comes from experience and that there is no inherent knowledge. It is rooted in the belief that in order to learn something, you must first do something. Then you inspect the outcome/results of that action, learn from it and adjust if necessary. I don't see how the effort of inspecting a defect to gain knowledge, then applying those learnings is not empirical. 
7. Isn't a Sprint Backlog a body of work selected by the Developers that they feel can be completed in a single Sprint that will satisfy the Sprint Goal? How is that any different than your statement other than you never mention a Sprint Goal?