How Defects should be handled in Scrum?

Most of your questions can be handled here:

http://ScrumCrazy.com/bugs

Thanks Charles I got all answers & my understanding was same. I posted this query to get view from expert like you to confirm my understanding.

Happy to help, just remember that this is only one way to do it and Scrum doesn't prescribe a specific practice here. I do believe it is a great complementary practice of course. I have yet to see anything that is markedly different AND *better* than this approach.

What does PB and PBI refer to ?? :-)

PB-Product Backlog, PBI-Product Backlog Item

To add to this conversation, I think the point here is, don't be afraid to talk. Communication (conversations) is essential. In a scenario like this, don't be afraid to talk to your team and the PO. The work in the PB should continually evolve as work continues. The priority of the work item will determine how urgently a solution is needed.

>> Should all defects be added into PB as a PBI irrespective of it needs to be fixed immediately or can be deferred?
>> Is there any guidelines which says if the defects found during current sprint needs to be fixed always in current sprint?

Charles is right, I don't think the scrum framework explicitly provides any guideline on when defects can be fixed.

Having said that, here are some thoughts :
From scrum guide : "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product"

Since defects initiate a fix, so yes, defects are PBI & should be part of PB. If you don't include defect in PB than PB no longer reflects all the changes made on product.

How to handle Defects found within a sprint : The process may vary from team to team. However, please remember "At the end of a Sprint, the new Increment must be 'Done', which means it must be in usable condition and meet the Scrum Team’s definition of 'Done'.". If you know of any obvious defects in PBI you have completed in a sprint, will you consider it as "done" & release it? I think not, but that depends on your DoD. If DoD has set some quality goal, you can't reduce it within sprint. Hence if that PBI doesn't meet the quality goal set in DoD (because of associated defect) than it should be considered incomplete & returned to PB for re-prioritization & re-estimation.

Scrum does not prescribe a specific method of manner to fix a defect during a given sprint. However, there is a general rule in Scrum that promotes the following:

"Anything that impacts the intended product needs to be listed into the product backlog".

But, the question remains - How quick and with what urgency should the defect be handled ?

That depends on many factors (complexity, priority and how serious is the impact on functionality) ) but generally speaking when a defect is detected during a sprint it should be analyzed and a course of action should be determined with the consensus of both the team and the product owner if possible. One course of action is to try to fix the defect within the current sprint otherwise a work item related to the affected user story should be created and placed in the product backlog where is can be scheduled to be completed during the next sprint or any other future sprint.

1. How these defects should be handled in Scrum? Should all defects be added into PB as a PBI irrespective of it needs to be fixed immediately or can be deferred?

First of all Defects and Bugs have different definitions. While there is no single source of truth MOST agree that..

Defects (or Production defects) is a missed functionality or flaw in the production software that was already released while..

Bugs are errors found in code during peer reviews, testing (unit testing, etc) which is considered part of the development effort along with coding (development is not just coding, it includes, testing, research, documentation, design, big fixing, any integration, DBA tasks etc!)

Any production Defect should therefore be part of Product Backlog and handled in the usual refinement meetings for prioritizing, estimating and adding details (adding details usually is not the case for a well documented defect !). It's the Product Owner's job to inform the team about its priority by ordering it in the backlog. The development team will pick it into the next or current sprint (Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned + No changes are made that would endanger the Sprint Goal - Scrum Guide) as needed.

2. Is there any guidelines which says if the defects found during current sprint needs to be fixed always in current sprint? For example if a defect found in current sprint leads to a new requirement then still it should be fixed in current sprint?

You answered part of your question in the second part :) Yes, if the bug identifies a new requirement the Development team and PO can clarify and re-negotiate whether this new Requirement should be estimated added to the current sprint or put in the backlog as long it is not impacting the Sprint Goal. 

If the Bug is however a coding error or incomplete work (does not satisfy the acceptance criteria) or possible technical debt it needs to be handled as part of the PBI as per the terms of Acceptance criteria and/or Definition of Done of the entire Increment. 

The practice I recommend to my teams is this.

If you feel the bug/defect will prevent the use of what you are building or achieving the Definition of Done, fix it now. If the increment can meet the Definition of Done with the bug/defect still in the work and the team is ok "releasing" with the defect in place, put it into the Backlog as a story.  That way it is handled just like anything else. 

After all it is just code being written. Too many people try to handle bugs differently.  If a developer writes code and then executes it locally only to find something wrong what do they do?  They fix it.  Why should it be any different if someone other than the actual developer writing the code finds an issue?  And what software ever released didn't have defects in it, known or unknown?  Don't over think this stuff.  Make it simple, repeatable, and above all intuitive.  

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

 Charles Bradley Your link does not work, perhaps this is the updater url?

Here it is, Patrik

How do you estimate fixing a Defect? 

I mean, obviously if the cause is obvious, then it can be written into a story and estimated.

But with most defects the cause isn't immediately obvious. You can't plan and estimate for something when you have no idea what it is causing it and what it is going to take to fix it.  I mean you can but your accuracy is going to be too variable to be trusted.

Estimating bugs is really no different than estimating a story.  Sure you can refine a story over time to a situation where you know more about the work.  But I argue that if the developer has knowledge of the code base in which a defect exists, they should be able to estimate based on their current knowledge.  And when there is more than one individual involved there is a better chance of uncovering what to do about it. Yes, it will be variable but so are estimates on stories when you start doing it.  Over time, as the knowledge of the code base grows your estimation of bug fixes will get better. 

Remember that estimations are relative to other things that they have estimated.  So if you estimate bugs relative to other items that have been estimated, it can start to become easier.  For example ask the question "do I know more about the possible cause of this bug than I did about the two 4 point bugs I fixed last?" or "Do I feel like the effort to do discovery and fix this defect is greater than it was to implement that 8 point story to add a feature?". It will get easier and the estimates will start to level out, just as estimates on stories did. 

Treat all items in the Product Backlog equally as everything there is created to provide value.  Everything in the backlog has 2 values.  Negative value when it isn't done, and positive value when it is done. In my experience treating them differently usually adds complexity that can cause confusion and conflicts when determining what value to focus on delivering during a Sprint. 

How do you estimate fixing a Defect? 

I mean, obviously if the cause is obvious, then it can be written into a story and estimated.

But with most defects the cause isn't immediately obvious. You can't plan and estimate for something when you have no idea what it is causing it and what it is going to take to fix it.  I mean you can but your accuracy is going to be too variable to be trusted.

What about root cause analysis, and/or conducting a technical spike investigation when refining the item on the Product Backlog?

Note that undoing problems is often harder than developing from scratch. That’s why it’s important to have a rigorous Definition of Done which minimizes waste caused by defects and technical debt.

What we do today is basically a technical spike, but what we've found is that more often than not the result of the technical spike is the actual defect fix itself.  Often you have to fix the defect to know if that was really the problem.

In that case we create a 0 point story (0 points since it wasn't estimated, but a story so that the work can be tracked) that encapsulates the defect fix.

In the case where the spike results in identifying work to be done, then we make a normal story and move on as we normally would with any other story.

However, those spikes themselves aren't estimated, nor do they appear to be reliably estimable.  That throws the Sprint itself into a bit of chaos since if the investigation goes long somebody's stories aren't getting done.

However, those spikes themselves aren't estimated, nor do they appear to be reliably estimable.  That throws the Sprint itself into a bit of chaos since if the investigation goes long somebody's stories aren't getting done.

Why would a product backlog refinement activity need to be estimated at all, and why would it have such an effect?

John, Spikes need to have two characteristics:

a) are time-boxed, cannot last more than the agreed maximum length;

b) have a clear defined output. A spike is ended when the output is achieved or the time-boxed expired. If the time-box expired and the desired output is not achieved the Product Owner needs to decide if he wants to invest in another Spike.

Estimating bugs is really no different than estimating a story.  Sure you can refine a story over time to a situation where you know more about the work.  But I argue that if the developer has knowledge of the code base in which a defect exists, they should be able to estimate based on their current knowledge. 

I favour another approach: don't estimate at all. The mere act of estimating bugs is, in my view, a waste. What could they estimate, really? How long it'd take to fix? Most always, the hardest part is locating (identifying) the bug, not finding and applying the solution.

Bugs need to be ordered, and as long as the PO is aware of the impact (SDLC), they (bugs) would get covered. If the bug is too severe (top priority), it would get immediate attention. Less severe - PO decision.

Bugs require two things only: investigation & fix. One can hardly estimate how long investigation's going to take. Once the (likely) cause is found, either a fix is applied or there's a need for another action. The action could be, for example: create a new ticket (ie, fix is complex/difficult, requires an estimate; fix has a dependency on another team and would require an estimate), create a spike to investigate possible solutions (unknown to the dev team), create a ticket (ie, the bug isn't really a bug, system's working as planned/designed > but a new implementation is required to make X work).

Our use of Spikes is similar to @Ionut-Adrian but not exactly the same.  Our Spikes all have a time-box determined prior to starting the work.  However, we use the time-box as an agreed upon point at which everything learned is evaluated as whether it answers the question that was being asked. Determination is then made as to whether additional time is needed (new time-box defined) or if this effort is complete as it can be at this time. We also treat any actual work done during the Spike as throw-away.  It could be used but there is no expectation that it will.

@John, I will admit that I never thought of handling bugs in that manner.  I actually think that is a good option.  Fixing defects always requires some level of investigation into the problem.  And as you said, often during the course of that investigation, the fix is determined and can be implemented rather quickly.  So creating Spikes or them is not a bad idea.  But as per the acceptable practice on Spikes, put a time-box on it using something similar to the ideas that have been provided here that will work for your organization.

As for the chaos caused I believe that should be manageable due to the Daily Scrum and a time-box placed on the Spike.  Each day the Development Team discusses what is in progress and plans for the work until the next time they meet.  During that discussion any impediments are identified that put the Sprint Goal into jeopardy.  If the work on a bug is affecting that then discussions need to be had with the Product Owner as soon as possible.  That leads to negotiation of the Scrum Team on how to adjust the Sprint in order to provide the best value possible. If the defect is deemed more important than the feature work, some of the feature work can be deferred to the Product Backlog.  If the feature work is more important, the defect is deferred and all of the newly found information can be captured and used for the next iteration. 

Again, thanks for the idea.  I really do like it and expect that it will come in handy in the very near future. 

@Eugene

I favour another approach: don't estimate at all. 

I actually agree with you if you insist on using a "bug" type and didn't really make that clear in my narrative.  I advocate that nothing is a bug. Everything the Development Team does is intended to provide value and should be treated equally.  Bugs are actually technical debt and should be treated as such. If you needed to do an infrastructure upgrade you would most likely create a technical story not a bug.  I see fixing bugs the same way. 

But if your organization absolutely can't live without a "bug" or "defect" item, by all means skip the estimating and just know that there is some level of uncertainty in any Sprint forecast that includes them to be worked. 

And in the sake of full transparency, I have 3 teams and our organization doesn't really provide any "standards" on the bug vs story thing.  So 1 of my teams insists on having a defect type in their backlogs.  And that team struggles with everything being discussed in this thread on a constant basis.  The two teams that do not use defect types have actually become quite fluid in their delivery and have actually started to complete more bug fixes and technical debt items than when they started.  The Product Owners have become mentioned that it is much easier for them to order if they do not see them differently. There is a psychological affect in play. Is it because of my theory?  I would like to think so because it makes me look good. But I honestly have no way to prove it so I give the glory to the teams for being a highly functioning self-organizing teams as all good Scrum Masters would.  :)

Great input, as always, Daniel!

Your points make sense. I guess it's safe to conclude, one more time, there's no one size fits all scenario, and teams use what they are coached, what they find useful, etc. No two teams are ever the same, no two people are ever the same.

PS: I'd have a different view as to why we shouldn't treat software bugs as technical debt, but that's another topic, and don't want to spam the thread :)

What is meant by the term "bug"? This question is answered in several different ways, depending on who you ask and when you ask them. These are the most common answers I hear when I ask this question:

1. The documentation says the system should do X when I press that button, but in reality it does Y.
2. During the acceptance test, the user had expected the system to do X when they press that button, but the system wasn't designed to do that. 
3. We couldn't completely automate test scripts 9 and 14 for story 123. The PO accepted this as the test cases are highly theoretical. So story 123 was considered Done and the PO put two bugs on the product backlog to develop the last two tests.
4. The system contains technical errors and has become unstable.

As you can see, the definitions of a bug and what caused them are very different. It's not really possible to give you a one-size-fits-all answer on how to deal with all these situations. 

If you look at numbers 1, 2 and 3, they are all basically plannable work that can be done in a future sprint if and when they provide sufficient value. The system does not do what someone expected, but no smoke comes out of it and no alarms go off.

What you could do is:

1. Update the documentation so that it describes what the system actually does. If needed, add a PBI and maybe change it at some time in the future.
2. Explain to the user that this was not anticipated. If needed, add a PBI and maybe change it at some time in the future.
3. If the test cases are really highly theoretical, then get rid of them. You can always add a PBI later if needed.
4. Drop what you are doing. Do it now. During the sprint review, explain to the stakeholders that this occurred and what you did about it. During the retrospective, investigate the occurrence and decide if you urgently need to implement a structural preventative measure. If yes, put it on the sprint backlog during the next sprint planning.

My personal preference is to just distinguish "plannable work" and "ad-hoc urgent work". The former includes stuff like use stories, bugs 1-3, Java version updates, spikes, etc. The latter just needs to be dealt with now.

Depending on how often ad-hoc urgent work arises, you could take this into consideration during the sprint planning. You may want to have a look at Scrum with Kanban to deal with the mix of plannable work and ad-hoc urgent work.

Hi everyone, from PO's perspective, if bugs also go into the next Sprint's backlog, then it means bad Sprint delivery quality and fewer new stories in the next Sprint's backlog. The more bugs in the next Sprint backlog, the worse the overall delivery quality. How can the team improve to have fewer defects in general?

How can the team improve to have fewer defects in general?

What are your thoughts about a Definition of Done and when it should be inspected and adapted?

Defect Triaging is a formal meeting where all the defects of the current Sprint are discussed and triaged i.e. Prioritized.

The QA Developers in the Development Team demonstrates and explains the defects to the rest of the Scrum Team. Based on everyone's input, the defects are then organized and classified into different categories. For more detail analysis you can contact to expert Professional in Scrum or Agile.

@Ravi - Google suggests you may be copypasting from here. Let me first say that this is not part of Scrum as defined by the Scrum guide. Second, there's nothing wrong with evolving processes around handling defects, but the idea of "a formal meeting where all defects of the current Sprint are triaged" (even 2-3 times per sprint, and the full team is required every time) strikes me as very strange for mutliple reasons. To cut it really short, a good team is awesome at fixing defects, a great team is awesome at not having any :)

I find good practice is to :

1. Triage all Bugs as they come in, triaged by developers, 2 hrs.
2. If the developers feel it is critical then fix it now. If not then move it to next Sprint.
3. Leaving Bugs in the Backlog is a waste of time.
4. Reviewing Bugs on mass is a waste of time.
5. Keep the Bug count at 0 for the current release. If your not going to fix it in the current release then close it

Let me know what you think

Hi new to scrum here, can I get an example of a defect? and how to resolve it?

Defects should be handled in Scrum by following the same principles as when developing the product. This includes breaking down the defect into smaller chunks, assigning tasks to different teams, and ensuring that the tasks are completed within the sprint timeline. The Scrum Master should also be responsible for tracking and monitoring the defects, so that any issues can be addressed before they become too big of a problem. Additionally, the Product Owner should prioritize the defects and ensure that they get addressed in a timely manner. By following these principles, defects should be handled efficiently and effectively within the Scrum framework.