How to differentiate old bugs from new bugs during a sprint?

Question

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

Currently,

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?

Answer 1

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.

Answer 2

TL;DR

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!