How do you assign a bug to a specific feature ticket?

[Sławomir Jałoszyński]

As part of a sprint, the team works on creating a new functionality.

During QA of this functionality, we detect a bug (dev, stage). I want to link this bug to a specific story within which the functionality was created.

The purpose of such a connection is to verify how many times the same improvement is fixed by different teams. To sum up, I would like to compare the story original estimate with the time that was spent on fixing bugs for this story.

I use the Tempo add-on to measure time. I also use issue type bug primarily to handle tickets on production versions where the environment, version, etc. are specified.

Of course, I also use the "linked issues" option.

What are the best practices in such a case?

Should I create a new subtask type, for example, called "bug-dev" and filter all such events by the issue type? As a result, each bug will be a subtask to a story in a new category.

[Jack Brickey · Accepted solution]

You might wanna consider the following scenario given your requirements to compare effort spent on bugs versus effort spent on the feature.

1. If, and when a bug is first found associated with a feature, create a "feature – bugs" issue, e.g. summary = "Feature ABC-123 - Bugs", and link that issue to the original feature. Also create a subtask for the first bug that is recorded.
2. The development team should record the time they spend on the bug sub-task.
3. Each subsequent bug would be added as a subtask to the feature-bug issue.
4. you can use automation to sum up the total time logged for each bug subtask, when the bug issue is marked done, and record it in the parent feature-bug issue.

[John Funk]

Hi @Sławomir Jałoszyński  - Did you get this working? Did you implement what Jack suggested? 

[Sławomir Jałoszyński]

Hi, @John Funk Unfortunately, I was unable to implement the solution below in this specific project, but thank you for refreshing the issue. The process of the number of bugs itself was limited by another Jira QA add-on. Additionally, the team proposed other solutions during the retrospection, which enabled monitoring environments in dev/stage versions for the Teams application. Nevertheless, the proposal is interesting and worth implementing.

[John Funk]

Okay, sorry it didn't go as you planned. But thanks for updating us!