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?
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.
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.
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
I've seen several approaches.
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"
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.
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).
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).
Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...
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!
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