Best way to track bugs for stories?

[Doug Varn]

Hi all,

We're just getting going with GH. Our stories in development are now being tested and the need to write bugs relating to them has come about.

I'm at a loss for an easy way to track bugs written against stories within a sprint. What I see so far is something like this:

1. Tester writes a bug against a story that's in the current sprint.

2. Tester can only associate it with the story either by the Link method or by applying a label that will be common to all bugs for this story.

3. The new bug then shows at the bottom of the backlog, not in the sprint.

I want to see what others do. The problems with this are:

1. Bugs have to be manually moved from the bottom of the backlog into the current sprint, unless they are very low priority.

2. There's no easy way for a developer to see all the bugs pertaining to the story on the scrum board, even after it's moved into the sprint. We use swimlanes for stories and subtasks, and bugs related to the story do not show up here.

3. The Link method doens't provide much visibility, not at all in the scrum board, and isn't useful for bug/story relationship visibility.

What I can envision as my ideal world is:

1. Tester writes bug against a particular story and has an easy way to instantly associate it.

2. If the priority of the bug is above a certain setting, then it automatically goes into the current sprint.

3. The bug shows neatly grouped in the swimlane as a sub-task of the story.

Essentially, I'm hoping to automatically include priority bugs as tasks within the story. The story is not complete in our world until all priority bugs are finished. So far, I don't see any easy way to achieve this.

Curious what others do.

[Doug Varn · Accepted solution]

Well, we decided to skip out on the need for visibility of bugs within GH. Our teams now will apply a label to each bug matching the corresonponding Story's ID (ex: WEB-89). Then the tester will provide a link to the filter as a comment in the story so we can all reference the bug list there. The testing sub-task of the story then is not closed until all the bugs in the list (above a certain priority setting) are closed.

I still would like to see GH/Jira somehow better and more automatically associate and link together bugs with particular stories in the future.

[Ted_Epstein]

Renjith, you may personally not see a need for organizing bugs, tasks and other issue types within stories. But on this thread and related threads, users have clearly explained very reasonable uses for this missing capability, and have pointed out the limitations of the various workarounds.

It seems that Atlassian doesn't want to add multi-level hierarchy (fixed or user-defined) to the issues schema. Maybe the problem could be solved in Greenhopper, by recognizing links of a certain type?

I hope Atlassian will consider this, because I think it's a serious shortcoming.

[Melania]

Hey! Did you find any new way or tool to deal with this since your original answer from 2013? :)

[Jennifer Bonck-Furlan]

JIRA has the ability to create custom subtask types, so you could create a Related Bug subtask and open it under the story directly. 

[Benjamin]

It's really weird that something that simple is not done by default in JIRA... Even in the new Next-gen project you can only have one type of subtask: Subtask. Whereas basically all over the community everyone says the subtask type: Defect or Bug is missing.

Most organisations have 2 modes: project and maintenance. I feel Atlassian templates are mainly focused on Maintenance... Otherwise I don't see how any project manager would not like to see her/his defects related to a story in the scrum board: it's supposed to be digital post it and that's how it's done every where :D

[JD Lobue]

Ugh! All this discussion and ambiguity on something that other simple tools handle out of the box. This is another example of why Atlassian fails to make complex, complicated, and often chaotic - simple. Going back to a physical board would be better. :-)

[Renjith Pillai]

In my opinion, there is no need of extensive tracking of bugs within a sprint. For a story like we create technical tasks, the bugs is sufficient to be created as a sub-task, IMHO. And may be add a validator, sub-tasks blocking condition, so that it is not missed while closing the story.

[Arwen.W]

The idea of "Story Bug" is not convenient enough. As the low priority bugs usually won't be fixed in the current sprint, and will be  converted to bugs and go to the backlog. So if we want to run a report of the quality profile of a story, those bugs will not be counted. 

Currently, what we are trying to solve this issue is

1) QA report "bug" and link it to a Story, if the bug is high priority, then test will assign the "bug" to current Sprint; if not high priority, then QA will leave it to the backlog.

2) then we use linkedissues() to run quality profile for story(s).

3) but the status of the story is not connected with the bugs assosciated, which is still an issue to address. 

Anyone has any idea, or there are solutions after a few years?

[Ivaylo Stanev]

Same problem here. We use Kanban/Scrumban but still need a good UI visibility for bugs linked to tasks.

We also need to know how much time a story, including all bugs found and fixed, has taken. Now, the only way to do it is by creating bugs as subtasks. However, if you fill the bugs as subtasks, you will get wrong/misleading stats in Jira concerning the total number of bugs etc. Besides, Bonfire logs bugs as linked separate tasks by default.

So, both options, bugs as separated linked tasks and bugs as subtasks, do not fully meet our needs. Some UI/Usability improvements are highly needed I would say.

Any better suggestions?

[paulredmond]

IMO it is not technically a bug if the findings are in the middle of a sprint working on a story. What about test sessions?

[Terry Beavers]

+1 with Paul Redmond's comment.

If a Story fails testing during a Sprint, you typically wouldn't create a new Bug ticket against the Story, but instead, fail the Story back to Dev with comments surrounding the acceptance criteria that failed.

[Another agile delivery person]

I too would like to be able to create bugs as subtasks of stories that are implicitly included in the active sprint (assuming the story is in the active sprint) You should also be able to create standalone bugs, as you can do already. Its not much of an ask and is something that other tools simply do out of the box.

I rail against the that's not the right way to do it argument, its the way we want to do it, lets have the option and the flexibility to use the tool the way we want to use it.

[JD Lobue]

All the discussion that a defect is only after release is based in traditional thinking and not in an adaptive mindset. Agile development allows for defects/issues/bugs within iterations and as the work is being developed prior to release. Some of those may need to be addressed and / or fixed before a feature can be released. Others may be deemed not needed or not needed before release and can wait. All determined by the PO.

[Tom McCarthy]

We don't consider changes to something found in UIT or SIT as bugs either.  Our definition of a "bug" is something found "after release", we refer to those as "fixes". We also have an issue managing the workflow of of  movement between DEV and UAT/SIT however.  I have been looking for an add-on or script to manage that flow.  Some people, especially in Kanban don't care as long as there is steady movement towards release.  I think it's important because it surfaces issues that PM and Dev Leads can work on to improve the overall dev process.  Lots of movement between Dev and QA can mean:

• You have a dev who is not validating his or her work well
• You have a dev who's shortcutting
• You have a problem with story definitions
• You have weak acceptance criterea
• Your per dev workload is too heavy causing them to move an 80% finished product into QA

and so on.  

As for a solution, we are testing two approaches; 1) Keeping the entire conversation in the original story, so you have an at-a-glance view of the development from start through release. And 2) Close a story when it moves to QA (thoretically the dev has done what they are supposed to do) and then create a new QA story referencing the original in the Story Summary (in JIRA, it becomes a link).  We use that as the tracker for the QA side.

Niether has surfaced as the "right" method, but they both work.

[Melania]

Hey @Tom McCarthy Did you find any new way or tool to deal with this since your original answer from 2017? :)

[alexlopez]

I'm also interested in what you are using nowadays since your answer back in 2017.

[paulredmond]

The idea of "bugs" in a story is incorrect. This is a new feature that is not complete yet, thus, I would argue cannot technically have any bugs until it is accepted. Bugs would come after acceptance.

The best way to track a missing key Condition of Satisfaction or missing requirement is a test session. After starting a test session for a story all screenshots will show up in the test session. You can even create new subtasks or raise new bugs if the new story creates a regression issue on an existing feature.

[JD Lobue]

What do you call defects that are a part of the development cycle before they get to production? I think you are only speaking about escaped defects here and not thinking about how defects can come at any place within the SDLC.

[Benjamin]

I agree with @JD Lobue , when you are implementing a story in a dev environment you need a way for the dev and test team (among others) to communicate, so the dev, deployment in dev env and testing will be split in several subtasks but the test team needs a way to mention an issue or a bug or a defect (maybe there is an official word I don't know) to the dev team

[Ivaylo Stanev]

Renjith, thanks for sharing. It makes sense, but still not the best solution, especially for Kanban.

We are using Kanban/Scrumban and it makes sense to track all bugs. We use the 2 Kanban charts to monitor how well we do with bugs and improve over time.

So, I would say, some software improvement (logic / UI / Usability) might be needed here.

[Renjith Pillai]

Yeah, scrumban is a slight issue in GH as there is not way to limit the issues in a Scrum board.

But regarding bugs as sub-tasks, I am still thinking that it is sufficient if you have a Kanban or Scrum board (just for bugs) and look at the cumulative flow diagram to see the overall improvement. Does that help?