In a sprint where we fix old bugs as well build new features, we will encounter 3 types of "bugs" in in a scrum board:

  1. Bugs introduced by current stories
  2. Bugs newly discovered during sprint but are not from current stories
  3. Bugs previously identified and planned in backlog and are moved into current sprint to be fixed


for (1), these are created as sub task issue type under the story to be worked on as part of the story. Stories are not done unless all sub tasks are done.

For (2), we create them as bug issue type in the current sprint so that we know how many bugs are discovered mid sprint.

Problem is with (3). Since they were bug type in backlog, when moved to sprint they continue to have bug issue type and this messes with (2).

What is the JIRA way of differentiating between old and new bugs during sprint?

I am very tempted to convert all type (3) Bugs to Tasks and Change Requests to Story at the beginning of sprint. Is this acceptable JIRA practice?

  • What are you trying to achieve? Your current process looks good, but perhaps you need to either link the bug to a completed story and/or add a field for "sprint discovered" and filter based on that. – Thomas Owens Nov 16 '16 at 14:53
  • Often times as PM I will be asked to produce a list of type (2) "bugs" so that Sponsor and Product Owners can determine if these bugs should be added to scope to be fixed. I want to use JIRA issue filter to automatically generate this list by JQL Type=Bug. However, the type (3) bugs are getting in the way because they are also JIRA bug issue type. The bigger question is, what is the significance of the "bug" type for type (3) bugs when they enter into a new sprint from the backlog? It seems to me they should be converted to task or story types at the start of sprint. – Jake Nov 16 '16 at 15:19
  • 1
    I think that converting type 3 bugs to stories or tasks is wrong - they are bugs. I guess I don't see a distinction between 2 and 3 - both are from previously "completed" stories. 1 is different - you should fix those before calling a story complete. But 2 and 3 can both be either brought into the sprint or deferred to a future sprint, since the defective software is already live in production. I think it's useful to be able to track errors and defects that weren't detected as part of completing a story, and you can do this by identifying them as bugs. – Thomas Owens Nov 16 '16 at 15:54
  • I've started to use similar approach recently. During a Sprint when a story is still in progress there are new bugs discovered (caused by the actual on-going development) then I started to convert Bugs into Sub-Task of the related story. We also use two boards - one for agile development and another one for bugs. The problem I'm struggling with is that sub-task are not reflected on Bugs Board and vice-versa. I can add Bugs to Sprint but then they appear under Other Issues and if I start to move Bugs around, one day they are on Bugs Board and then are on Agile Board which IMHO is a bit messy. – iaforek Nov 23 '16 at 11:10

I just wanted to expand on my comments on the question, as an answer.

Of the three types of defects that you identified in the question, I only see two types of defects. The first one, bugs introduced by current stories, is an in-phase defect. The other two are out-of-phase defects.

The concepts of "in-phase" and "out-of-phase" come from the measurement of defect detection efficiency or defect removal efficiency. In a sequential model, a "phase" is an activity of development - requirements, design, coding, etc. In an agile methodology, I'd consider a "phase" to be an iteration. If you do not release at the end of every iteration, you may consider a "phase" to be a release, as well, but I think that it is easier to track each iteration as a phase.

If you detect an issue before a story is marked as Done (as defined by your Definition of Done), you can create a subtask on the ticket. In the instance of JIRA that I use, a Story can have different types of subtasks, one of which is a Story Bug. A Story Bug would indicate that an issue was found in code review, independent QA, or acceptance testing that needs to be resolved while a Task subtask would simply be something to do.

Once a story is marked as Done, if there is an issue with it before the release (perhaps because of a conflict with another story or change made), it can be reopened and an appropriate subtask added. However, any issues found related to a story or task that has already been released are put in as a Bug, which is a top level task type in JIRA. It's also linked back to the appropriate story for record purposes, but the original story remains in a Released state.

If you also add a field in JIRA to track the Sprint where you suspect the issue was injected, you can do some more fine-grained tracking about the age of the issue. This may help in prioritizing. However, it may not be entirely accurate - you may not always know for sure when a defect was actually injected into the software, but you can guess based on file change history.

When reporting, there's no reason to differentiate between what you are considering type two (bugs discovered but are not from current stories) and type three (bugs from previous work that are moved into current sprint to be fixed) bugs. If, in the course of doing work on an iteration, you find a bug that has yet to be reported and exists in released code, simply enter it as a bug and have it go through your triage process. If it's severe enough, you can adjust your iteration scope. If it's not, you can prioritize it for the next iteration.

  • Unfortunately, sometimes in practice, it is a requirement to differentiate bugs, and not whether there is a reason to differentiate between different bugs. So I would like to use JIRA as a tool to do it rather than manually keeping a separate list. Hence I hope to seek advice from other PMs who might have found a way to do this effectively with JIRA. – Jake Nov 20 '16 at 4:12
  • @Jake Did you read the paragraph that is second from the bottom (the 6th paragraph, including the line at the top)? In the event that you need to do what you are trying to do, that is the solution. You can even add another field - sprint detected - to make it even easier. Bug type 2 is where sprint injected is not sprint detected, and it becomes bug type 3 when you move it into a backlog. Bug type 1 is simply everything of a particular subtask type. But as a lean advocate, I'd want to know why this is required, it doesn't have any management advantages and only requires more data collection. – Thomas Owens Nov 20 '16 at 11:11


Bugs are defects found after an increment of work has been released. Work-in-progress is either done or not-done; almost by definition the current agile increment should not be generating "bugs" in the ticketing sense of the term.

Released Defects vs. Incomplete Increments

Some of the problem may be the way that you're treating defects in features that are under development within an iteration. Your question implies that there's some sort of internal cycle to your iterations where "bugs" are being tracked as defects, rather than simply treated as unfinished or incomplete features that don't yet meet the Definition of Done.

For example, if Feature Foo from the current iteration isn't passing the acceptance criteria defined for the feature (you are using some form of test-first development, right?) then the work is simply "not done" rather than a bug. If you're tracking it as a bug, it strongly implies that your developers and your testers are not actively collaborating. I'd treat this as a process smell, rather than trying to create some new category of "work-in-progress bug" that should be tracked separately.

On the other hand, if Feature Bar met the Definition of Done in a previous iteration, but bugs were later found after the feature was declared "done," then while you may choose to log it as a bug in JIRA, from an agile perspective it's really new work for a subsequent iteration.

Active Collaboration

Collaboration in an agile sense is about working together, in as close to real-time as possible. In software development, this generally results in patches, pull requests, or red/green/refactor cycles rather than team members filing tickets against each other's work.

If you have testers filing bugs against work-in-progress, you need to improve your process to create closer collaboration. This may require moving the testers into your development team rather than treating them as external resources, or training your developers and testers in pair-programming or test-first development practices.

You want to foster collective ownership instead of finding new ways to file or track tickets. You have a real opportunity for significant process improvement here; focus on the process, not the tool!

  • Actually my objective is to differentiate old bugs vs new bugs, and not trying to understand what is a definition of bug -- i.e. Released Defects. Imagine we have an entire backlog of bugs. At the start of the sprint we plan 20 to be fixed. Mid-sprint, we find new bugs that were not identified previously. In strict scrum way, we simply add the new finds to the Backlog because the Sprint Scope shouldn't change. But in a less strict way, suddenly 10 new bugs have to be fixed this sprint and 10 old bugs can't be fixed. If everything is Bug type, we can't differentiate and report via JIRA easily. – Jake Nov 20 '16 at 4:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.