How to deal with bugs in sprints

[davidrouse]

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?

[Steven F Behnke · Accepted solution]

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.

[davidrouse]

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 F Behnke]

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.

[Kudja]

Hi @Steven F Behnke, Hi @davidrouse,

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

[Shahid Rafi]

Just one small confusion, if someone can answer please. What to do with the sub-tasks / defects, in case of spillovers? can we move these sub-tasks to next sprint independently? if required. What if some bugs are not fixed till the sprint deadline? 

[Nic Brough -Adaptavist-]

You should change your process so that you do not have "spillovers".  If you're getting them regularly or lots of them, then your process is broken - you're estimates are too low or you are trying to bring too much into your sprints.

If, as in the previous comment, you have things "moving from sprint to sprint", your process is wrong.  When that happens, you should always be asking yourself "why are we unable to deal with this?  Should we even be doing it?"

You say you are creating your defects as sub-tasks.  That's good, as you're seeing testing as part of the process of getting a story done.  So, when an issue has open sub-tasks, it can not be "done", there's stuff to do on it, so it is clearly not "done".  Stories in this state go into the next sprint when the current one is ended.  The whole story, not the sub-tasks - because you have not finished the story.

[Lalatendudas]

When QA tests a Card and finds a defect,

• tester creates a bug ( card) and links it to the Story with relation type as 'blocked by'
• Team can decide whether they plan to fix the bug in the same Sprint or later
  • if team decides to fix in a later Spirint, then both the Story and the bug are moved back to the backlog.  The Story card is replaced with the next eligible Story/task card with same story point size, so as not to effect the velocity
  • if the team plans to fix the bug in the current Sprint, then both the Story and bug are placed under 'In Development' queue  and a story/task of the size of the bug is swapped out so as not to impact the velocity.
    • Scope creep can be addressed by slicing a Story and swapping out a slice of it with the bug
• The bug will be fixed and the Story will be retested by QA  within the Sprint

[Nic Brough -Adaptavist-]

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"

[davidrouse]

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 .  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.

[Nic Brough -Adaptavist-]

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).

[Khalid Abi]

@Nic Brough -Adaptavist-  Considering Option 3,  How would you plan trivial/unimportant bugs to fix in the next sprint without having to carry over the User Story from which this bug arose?

[Nic Brough -Adaptavist-]

That would be adopting option 2.

[Arathi G Rao]

How about creating them as story bugs [scope creeps] size them as well  and take them into next sprints. these get accounted, sized and get visible on the burndown!

[Brenda Gilpatrick]

I have seen subtasks created for the issue, and label used as FoundDuringTesting-UI (or whatever the issue is), and tracked from there. Since subtasks are not pointed, no scope creep.

Once a subtask is created, it is assigned to the DEV over the story. The story is then moved back to Needs Attention --  When the dev has corrected the issue(s), they reassign each back to the QA for another look (and put the story back into the QA lane). When the subtask(s) are all good to go, the QA marks each as DONE .. and when all subtasks are DONE, the story can proceed to the next phase (release readiness). 

[Caesar Padilla]

 Adding work items outside the perimeter of a user story will add weight to the project scope and if this habit continues unchecked it will eventually lead to the condition known as scope creep.