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.
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.
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.
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.
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?
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.
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?
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.
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?
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:
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.
Every team in the world is unique, and so Atlassian believes that each and every team's best way of working needs to be molded to their unique circumstances – ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot