Should bug/regression tickets be reopened, or new tickets created?

Question

Question

This is a paradox I have: when I create GitHub Issues (or JIRA tickets, or whatever issue tracker you use), my engineers like to make them very granular, so that it narrows the scope down for them. But at the same time, when I hand over work to clients and they complain of regression bugs, I can either open new issues or simply reopen old ones (the former being the granular approach, the latter being the simpler-to-manage approach).

Which approach is better? I'll summarize the pros and cons of the approaches that we are considering.

Our Granular Approach

Pro

Narrows scope more for developers. Especially useful when you do delivery-based compensation since it limits the risk for developers.

Con

Makes keeping track of all these issues harder, especially when reporting progress to clients. For example:

1. Bug 324 was closed.
2. We opened 452 as a regression on 324.
3. 452 was fixed.
4. We opened 563 as another regression on 324, and it is in progress right now.

Our Simpler-to-Manage Approach

The easier-to-manage approach is simply the opposite of the granular approach described above.

Answer 1

TL;DR

You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage.

You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to make work visible. As long as the team and the organization all agree on how this is being done, and what it's communicating, either approach can work.

As a general rule, only improperly- or prematurely-closed tickets should ever be reopened. All other work represents new work with its own scope.

What Are You Tracking?

You are conflating "issue tracking" with "work tracking." They are never the same thing, although they can certainly be interrelated. Whether you reopen tickets or create new ones really depends on what you are trying to track, and how you plan to use the metrics.

You should strive to ensure that your process conforms to one of CodeGnome's Laws: "No Invisible Work, Ever!" Whichever approach you take, it should be clear what work is in progress and how much effort is involved. The status of the work should be clearly visible, and the process should remain transparent to stakeholders.

New Tickets

Opening new tickets ensures that all new work or rework is treated as a first-class tracking item. In particular, it prevents rework (whether from bugs or iterative development) from being buried as invisible work inside reopened tickets, or from inheriting legacy time/effort estimates that don't apply to the current work required.

Most ticketing systems, including JIRA and GitHub Issues, allow for tickets to reference or link to other tickets. When possible, I always recommend that any new work or rework be assigned a new ticket and a new estimate, and then link to any legacy tickets that might be related.

Reopened Tickets

While there can be other reasonable arguments, from an agile perspective a ticket should only be reopened when it turns out the closure was premature because the work on the ticket didn't meet the "Definition of Done."

If a ticket meets the team's Definition of Done, but regressions are found later or requirements have changed, then this is work that was not within the scope of the previous ticket. The ticket was properly closed; the bugs or additional scope represent additional effort required from the team to meet a new objective.

Examples

While not exhaustive, here are a couple of simplistic examples to help you think about the functional difference between new work and incomplete work.

1. A ticket to embiggen a widget was closed as complete, but the integration testing was not done. This ticket should be reopened and the remaining elements of the Definition of Done should be performed.
2. A ticket to ensmallen a dongle to fit a new Model B Widget was closed as complete after meeting the Definition of Done. However, no one realized that the dongle needed milled edges to fit the new model. This specification change is new work, and the work should have a new ticket even though the ticket can be linked to the "Prototype the Model B Widget" story.
3. A customer tickling feature was added to your product. However, 12% of your customers are being killed from ocular stabbing by the feathers' quills, and this issue has been classified as a low-priority bug by the sales team. Locating and resolving the source of the bug is new work that requires a new ticket, and should become a first-class tracking item. This ticket should then be prioritized appropriately by the Product Owner (or similar project role) and scheduled accordingly.

Tickets should only be reopened when they shouldn't have been closed in the first place. All other work represents new work with new scope, and should be treated accordingly.

Answer 2

The answer to this question is a simple one: you manage your work at the level of decomposition / abstraction necessary to manage your work.

This is a plus / minus equation. On one hand, by keeping it at the higher level, you increase the ability for flexibility in the work and you save a ton of money in tracking and controlling. But on the other hand, by keeping it at the higher level, you increase the risk of missing precious indicators of work performance degradation since those indicators will be masked in the summary performance.

Choose carefully.