nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

Steven F Behnke

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.

All comments

Steven F Behnke

Nic Brough -Adaptavist-

I've seen several approaches.

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

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

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

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

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.

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?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud