Estimating bugs (unplanned items)
Hi,
Is it common practice to estimate bugs/unplanned items?
Not talking about findings found during the sprint.
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...
I coach my teams to view bugs in a couple ways.
- 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.
- 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.
- 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?