Bug Triages

[Hennadii Omelchenko]

Hello,

Recently I've come across a practice in the organization which has been there from pre-agile times. It is called bug triages. I'm struggling to grasp the role of this one in Scrum as I've never met in trusted sources any reference to 'bug triages'.

• is this practice to be considered a part of product backlog refinement?
• won't bug triages meeting create another standing session in addition to 'official' ceremonies?
  
• how does it fit in Scrum (by spirit and letter),
• are there any alternatives to 'bug triage' meeting?

I would greatly appreciate all the opinions and thoughts!

[Markus Gaertner]

Hi Hennadii,

bug triages are mostly in place when the number of bugs is overwhelmingly enough that you need discuss which ones to fix now, and which ones to fix later, or not at all.

The perfection challenge that Scrum imposes on the organization is to get rid of these old bugs, so that triaging them is no longer necessary. At least that should be the goal.

Recognizing that you may not be in that state, consider dedicating one of your teams on a rotating basis to take care about bugs. If that's not an option, I would strive to dedicate one person from your team, while relieving the others of this duty.

Best

Markus

Scaling Agile as if you meant it: http://www.scaledprinciples.org

--

Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Andy Watkins]

Hi Hennaddii,

 

As Markus said, Bug triages are useful if you've got a lot of bugs. In my experience, dedicating one team to bug fixing, or one person in the team, is demotivating.

 

I would encourage you to triage the bugs so they're in priority order (a kind of backlog grooming), and then get the highest priority ones into the main backlog so they can be picked up alongside the other work you're doing.

 

An alternative that I've been involved in is to dedicate one day per week to bugfixing (e.g. Bugfix Friday)

 

However you look at it, the bug backlog _is_ part of your backlog, even if it currently looks like a separate list. You may find the list is quite long, and takes several "bug backlog grooming" sessions before you've got it under control

 

As always, try something and ask if it worked in  your Retrospective.

 

Andy Watkins CSM

--

Andy Watkins

[Rohan D'Sa]

On Mon, Feb 23, 2015 at 9:46 AM, Andy Watkins <an...@wis.co.uk> wrote:

However you look at it, the bug backlog _is_ part of your backlog, even if it currently looks like a separate list. You may find the list is quite long, and takes several "bug backlog grooming" sessions before you've got it under control

​Exactly. It is just another PBI, especially if a product owner says that it's something she can live with for a while.

However, most product owners would rather not go through individual bugs in every backlog refinement session​, so maybe it's a good idea to set them on the agenda every other time or something like that.

Cheers,

Rohan

[Ron Jeffries]

Hi Hennadii,

The notion of triage involves the prefix “tri”, which means “three”. In medical triage, emergency patients are divided into three classes: those who will probably live, whether they receive treatment or not; those who will likely die, whether they receive treatment or not; and those for whom immediate care may make a difference. Triage is a quick rule of thumb to decide how to allocate limited care resources when the demand is far too high.

The analogy, of course, would be to divide bugs into three classes (or some other number I suppose), to decide which ones get attention.

But I’d like to stop us right here. They are not “bugs”, that wander in through the cracks in the doors. Everything in the product is something that the developers put in (or left out) by their own actions. They’re not bugs. They’re defects. They’re defective work. The work was not really “done”. We’ll come back to that. I find that it helps to refer to defects because is reminds us that they are up to us, not some random event like rain.

The notion of “Defect Triage” seems to be all over the map in the literature, and is often associated with complex procedures of deciding whether a support request reflects a defect or a need for help, and so on and so on. It is possible that a procedure would be useful, but it seems unlikely to me that a standard procedure will work in more than one situation. That is, the details of processing bugs will always need to be specialized to the situation in hand.

Generally speaking, I find that dealing with defects in Scrum can and should be much simpler than most triage procedures.

In Scrum, the Product Owner decides what the team will do (and the team decides how much work to take on and how to do it). Therefore, in Scrum, the Product Owner decides which defects to fix, and which ones to defer. To have a separate stream of work, or a subsetting of the team who pull defects from somewhere, essentially reduces the Product Owner’s ability to get the best possible result by the desired date. It undermines the authority of the Product Owner, making it harder for her to do her job.

This is really never ideal. Dedicating a person or a subset of the team to defects is demotivating, as Andy pointed out. In addition, it costs the team the talents of those individuals over that time period. It weakens the team. Additionally, it weakens self-organization. The team is supposed to decide how to do the work, not some outside resource allocator. Even if the team wanted to organize that way, however, I’d recommend against it. As Andy also pointed out, whatever you try should be assessed and improved in the retrospective.

But wait, there’s more. 

At the beginning of some Sprint, there are N defects. 

How many defects should be in the product at the end of the Sprint? Well, if the team is producing an increment of “done” software, there should be no more than N. Suppose there is one new defect, in item A. What can we say?

First of all, item A is not done. Yet somehow we thought it was. What caused that? One common cause is that the team has a separate testing process that happens after the Sprint. This notion is terribly dangerous. It means that the team can never know whether it is done or not. Therefore it can never ship an increment of done software. But Scrum says we must. Therefore the process is broken.

Another possible reason — the only possible real reason, actually — is that the software was not sufficiently tested during the Sprint. Downstream testing or not, if we test the software well enough, the downstream people won’t find any problems in our code. So we’re not producing done software. Therefore the process is broken.

Now, I’m not one who says you have to do Scrum because you have to do Scrum. You do Scrum for what it provides, which is a visible flow of done software that enables the Product Owner to create the best possible product by the end date. If there are defects, the software’s not done, the information isn’t visible, and the Product Owner can’t do her job. You don’t get the benefit of Scrum. The benefit, the ability to actually steer your product to success, is what you should care about, not whether Scrum says or not.

So we cannot tolerate the defect count increasing, even by one defect, at the end of any Sprint. Naturally, we are human, and it will happen from time to time. And every time that it happens, we need to do the same thing, roughly this:

• Give the new defect to the Product Owner to prioritize into future Sprints;
• In the Sprint Retrospective, figure out what part of our process allowed the defect to slip through our testing;
• Improve our process so that that defect, and defects like it, will not slip through.

Note that we improve our process. This is not a witch hunt for “who wrote that defect”, it is a process analysis for “how did we, the whole team, not catch this, and what can we do to catch similar things next time?”

Typical improvements are these:

• Ensure that every Sprint backlog item has concrete acceptance criteria;
• Have acceptance criteria up front: see “definition of ready”;
• Improve those criteria as indicated to ensure defects like this don’t get through;
• Slice stories smaller, so that acceptance criteria are easier to write and check;
• Improve programmer-level testing to provide a second net of tests to prevent problems like this;
• Use test-driven development to provide programmer-level testing more reliably.

There are many more possible improvements, and many details to these. 

The fundamental points are:

• Scrum has a Product Owner who decides what we work on, who therefore decides what defects will be worked on,
• Each defect escaping the Sprint should be addressed in the Retrospective.

Note two important things about thinking this way:

First, ideally, our defect list will not grow: it can only shrink. Even if things are not ideal, it will grow far more slowly.

Second, if we work this way from the beginning, we’ll have far fewer defects than we did in the old days. How many fewer? Teams working this way report from one tenth down to one one-hundredth of the defect rates they had in the past. Teams quite commonly report one or two defect escapes per year into the live product.

This process is more effective, because it actually reduces defects at the source, instead of providing a fake sense that something is being done by pushing bug reports around on the table. 

At first this seems like it’ll be more difficult. Well, no. Fixing a thousand bugs is difficult. Frankly it’s impossible. Preventing them is easy. You just have to pay attention and improve your process.

Ron Jeffries

ronjeffries.com

Perfectionism is the voice of the oppressor -- Anne Lamott

[Hennadii Omelchenko]

Thank you all for your opinions!

To clarify a bit, I'd like to try to explain how this 'bug triage' is supposed to work 'over here' (to the best of my knowledge):

When bugs are identified over the course of the sprint, this BT meeting is gathered for the whole team with PO, where people discuss identified bugs, assign severity / priority, and decide whether to fix them in this sprint, or move to 'Bug Backlog'

понеділок, 23 лютого 2015 р. 12:40:35 UTC+2 користувач Ron Jeffries написав:

[Pierre Neis]

I use triage when the team is working on a new version (release) and need to fix something from the oldest version. Here triage is a part of Grooming and helps to improve the next Sprint Backlog. The outcome helps the discussion to balance between new feature (US) and technical debt.

      
PierreNEIS
Lean Agile Coach | Scrum Coach&Trainer | Agile Management Catalyst
M: +352 / 661 727 867
pie...@wecompany.me
Luxembourg | Paris | Brussels | Amsterdam | Beirut

[Rohan D'Sa]

​Ron,

Great mail as usual, I always learn something from these! Thanks for that.

Having said that I have a question:​

On Mon, Feb 23, 2015 at 11:40 AM, Ron Jeffries <ronje...@acm.org> wrote:

First of all, item A is not done. Yet somehow we thought it was. What caused that? One common cause is that the team has a separate testing process that happens after the Sprint. This notion is terribly dangerous. It means that the team can never know whether it is done or not. Therefore it can never ship an increment of done software. But Scrum says we must. Therefore the process is broken.

​Maybe item A is not done. But say a small defect, for example, a misalignment of a pixel or two (or whatever the PO deems not highly valuable) is left over. As part of the daily standup, the PO hears this and, based on the team's input, decides that the benefits of fixing this defect far outweigh the effort that needs to be put in and the next PBI is much more valuable than fixing this defect. Or that this was an acceptance criterion that wasn't thought of in advance. Or that it affects some other flow in the product in a way that we could not envision before.

Given the constant struggles of a PO, I see this is a practical scenario. Maybe she chooses to accept the risk, and since we want to make work visible, she raises a new defect or a new user story. How would you look at this situation?​ Do you recommend that the PO eschew cost-benefit analysis and kill all defects within a sprint instead? 

[Ron Jeffries]

Rohan,

On Feb 23, 2015, at 9:01 AM, Rohan D'Sa <roha...@gmail.com> wrote:

Given the constant struggles of a PO, I see this is a practical scenario. Maybe she chooses to accept the risk, and since we want to make work visible, she raises a new defect or a new user story. How would you look at this situation?​ Do you recommend that the PO eschew cost-benefit analysis and kill all defects within a sprint instead? 

Once a defect escapes, the PO gets to decide when, if ever, to fix it. The PO gets to say when things get done.

However, when a defect escapes, it forces the PO into having to decide on fixing the past vs improving the future. Therefore the team (Dev Team if you prefer) should bend great effort toward never letting a defect escape.

This seems costly at first glance, but on the average it costs lots more to fix a defect than to prevent it, so in fact, it costs less to work very clean.

Ron Jeffries

ronjeffries.com

 Speed is ppoor subsittute fo accurancy -- Fortune Cookie

[Rohan D'Sa]

On Mon, Feb 23, 2015 at 3:51 PM, Ron Jeffries <ronje...@acm.org> wrote:

the team (Dev Team if you prefer) should bend great effort toward never letting a defect escape.

​Agree 100%.​