This scenario has caused big arguments in my organization, and we can seem to come to a consensus.
I know it's a relatively trivial matter, but it's like a pebble in my shoe. It just keeps coming up and causing mild irritation.
The case
We initially have an issue, it can be a story or a bug. Let's call it A.
Someone reports a different bug. Let's call it B.
The person working on A sees B, and thinks that B will be resolved once A is done, as part of A. B is a small issue, smaller that A's scope. It's not a direct duplicate.
How should we handle the case?
Example
For example, A can be something like updating a navigation library, and B can be a problem with performance on a certain page.
In this example, the developer would state that the performance issues will be resolved with the library upgrade.
The argued solutions
Option 1
Some of us think that both issues should remain open. The person who reported B may not want to know of the full context of A. They just want to know when B is done. As such, the developer working on A now has to manage both issues in parallel.
With this solution, the risk is that the "potential duplicate" issue gets forgotten, or wrong versions end up associated to it. It increases management overhead since B not needs to always follow A, and the backlog gets polluted if multiple such issues arise. It also increases my WIP count, in that even though A is the only issue being worked on, I now see A and B as active.
With this solution, we have to pull all these potential duplicate issues into sprints, so that developers are actively monitoring B while working on A.
The pros are that it keeps the B reporter's scope narrow. The B author doesn't need to know about A. When B is closed, the reporter can verify that the narrow scope of B is working as desired.
One sub-option in this scenario is that we mark B as blocked by A. We don't touch it until A is complete, then we reevaluate it. It's still tedious, but the blocked status at least doesn't force us to track two issues at once. With this sub-option, the downside is that the lead time for issue B becomes long, and the reporter thinks that the issue they reported is being ignored.
Option 2
Others think that the developer's guess should be good enough to justify merging the issue. The content of B would get copied to A, and the person working on A now also has the responsibility to make sure that all the details that B added are addressed by A.
Using the example above, the developer needs to confirm that the performance issue really is fixed by the performance upgrade.
The pros are that each issue in Jira tracks one work item. We get better visibility on developer work. I know that when the developer finishes their work, the issue will be resolved. I don't have to manage tracking multiple issues in parallel, any my backlog is concise.
The cons are that the B reporter now needs to know about the bigger A issue, and will get sucked into a bigger UAT or verification.
Potential compromise Option 3
Some compromise solutions are that we keep both issues active. We place B in an interim special status, and either through automation or manually unblock it when A is resolved.
This doesn't address the problem about having many WIP or affecting lead time metrics, but it at least alleviates the need to pull B (and potential C, D, E, etc.) into sprints. Once A is resolved, B will be unblocked and ready to be pulled into a next sprint for verification.
Any advice or experience is appreciated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.