How to deal with bugs in sprints

We are running into an issue with bugs in sprints.  Lets say a developer reaches "dev complete" on a story and hands off to QA, we want to track all the defects that QA finds and have the developer fix them before we launch.  If we add the defects to sprint, JIRA treats it as scope creep.  It also makes the burndown chart go in the wrong direction as developers and testers add tasks to the bug.  

 

My question is, what is the guidance on tracking defects created in a sprint?  At this point we are considering having to track the defects outside of the sprint and link the defect to the story.  This is a pain in the ass for the developers because now they have to look at the board and a second board for defects.  It also makes reporting a pain in the ass.  Is there a clean way to accommodate this Jira?  

 

Before someone suggests filters, that is all well and good except for the fact that a lot of the JIRA dashboard gadgets and canned reports defeat the use of filtering and I find I'm back to punching data out of JIRA to google docs to generate sprint metrics for management which leaves me wondering why don't I just use trello if I am going to have to each this much pain.  This can't be this rare of an occurrence.  We are about to light up test rail tied into our test automation suite and have test rail be creating defects in JIRA as test cases fail so the issue is only going to get worse.

 

Anyone have any suggestions?

2 answers

1 accepted

4 votes
Steven Behnke Community Champion Jan 20, 2016

Most of the teams I've worked with have created a sub-task called Defect. Product bugs are entered as a normal issue of type Bug and Story defects are entered as a subtask of the parent story of type Defect. They don't estimate these.

Thanks Steven, that is pretty close to what I did.  I created a new issue type off subtask called Story Bug to differentiate errors in WIP from defects found in production.  We point stories.  Production defects are 0 points.  Subtasks and story bugs don't get points assigned.  We were hoping to use hours on tasks to get a more fine grained burndown chart and to have some objective data in retros when people say "We didn't spend THAT long on new defects". I guess we may have to run the burndown chart off points and deal with the predictability challenge looking at the chart.

 

btw, major respect for rocking a proper mohawk instead of a weak fauxhawk.

Steven Behnke Community Champion Jan 21, 2016

Haha. Thanks David. 

Unfortunately you need to be offering an Original Estimate to stat against so that's of no use to you. The usual though process is to just take the Defects as a lesson learned. It's technical debt, obviously classed a bit differently than typical Bugs. 

Future Bugs are harder to predict and fix. This constitutes as maintenance you could say.

Defects are easier to attack since they are happening within the process and are found more quickly. This is straight up debt.

Hi @Steven Behnke, Hi @David Rouse,

I'm trying to implement something similar, but I can't understand how you finally deal with bugs )))

If this is a bug during sprint then we totally can mark them in task and configure workflow as QA can click Back to development and dev would fix them. So I can't understand a point of that Defect / Sub-bug tasks in current sprint.

From other side if it is bug from production, but it is bug of just released future. You offer to create a new task with type bug and with estimate=0 on it. But what if this is something can take time to solve and we need to plan this? I mean what if this bug fixing can take for example 4 hours. In that case we need to plan this + me and customer wanna see this 4 hours in initial task Spent Time finally, because this bug can be some missed/incorrect part of initial task.

Option 3 below from @Nic Brough [Adaptavist] also not ideal as in that case we need to add/plan task with it's original estimate, not with Remainig that is including that bug 4h to fix in real.

Ideal for me probably can be reopen or even don't close original, but in that case we need to move it from sprint to sprint + we need to plan sprint based on Remaining Estimate which is not possible in JIRA

3 votes

I've seen several approaches.

  1. Track them separately, outside the project, so they don't affect the numbers.  This doesn't really work because you have to divert project resources to deal with them, and it's
  2. Add them as new issues.  Never put them in the current sprint unless they're critical and should be classed as scope creep.  In the next planning meeting, put all bugs at the top of the backlog and deal with them as the next sprint items
  3. Raise them as sub-tasks without estimates, and re-open the parent, as it's not "done".  As @Steven Behnke says.

Both the second and third work quite well, but you have to judge your users and be strict on process. 

If you reopen issues with subtasks, you need to make sure that your managers understand that you're doing it this way, so that when other things don't get done, you can explain that defects are hurting you. 

If you go for "next sprint", you often get whinging and incomprehension from users who think that because they found a bug, you should throw away all your planning and deal with it immediately.  You have to be strict on them and say "no, we can't plan if you do that, but we do put defects at the top of the backlog"

Thanks Nick,

I've done option 1 at another company, it is a pain.  To be clear I'm making a differentiation between bugs that people report from production, they are triaged and brought into backlog and then prioritized based on severity and what areas of the system are going to come under most heavy modification in the next sprint.  The bugs I am talking about are "developer is working on story x.  QA tests story X.  Story  x does not work as expected or creates a regression".  For these cases, the story does not move forward until bug free.  I was hoping to track and easily report on this type of thing with Jira's built in reports but there are a lot of limitations in that I can't put hours on those WIP bugs without it trashing the burndown chart (we are running the burndown chart off task hours to try and get an accurate sense of sprint progress and a better understanding of where we are really spending time in a sprint.  I may have to achieve that goal another way.  #3 is pretty close to what I was doing, I think I will just have to go with less icing on my cake smile.  Option two is doesn't deliver the degree of quality to our users that we want to so it would not be acceptable.

 

Thanks to you and Steven both for taking the time to reply.

Yes, the choice between 2 and 3 is not one I could make for you - it depends on your expectations, process and what you want to report on.

2 really does heavily favour simple and effective planning, and tends to work better when you have short-ish sprints - the longer the sprint, the longer the defect has to wait for attention.  3 is better if you have baked QA into the process and really don't consider "development done, but not tested" as "done", which a lot of teams do have to assume (often because QA is a separate team that they can't draw into proper sprint planning).

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,338 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot