Bug review for possible links/duplicates in Scrum

[Dan Shebunin]

In our organisation we are using Scrum process. In our version of Scrum, bugs created in backlog, along with a user stories e.t.c. Developers choose to pull bugs in sprint. When developer finishes to fix a bug, he will pass a module with bug fix to QA. When developer fixing a bug, QA engineers may find more bugs, that look different, but have a same root with a fixed one.

So, we have a situation: a number of bugs in sprint, and number of related bugs - are not.

I have an ugly solution: custom field "Need review". By default it's "No". But when QA finds, that fixed bugs are not only pulled to sprint, but also in backlog, he will set "Need review" field to "Yes" for bugs in backlog.

Developer have a quick filter in Scrum board called "Need review". He have a duty to check the bugs under the filter, and if it is some - review them, pull in sprint, set "Links" field and mark as Done.

I hope you can understand my messy explanations. Any recommendations how to do it a smart way using GreenHopper are very appreciated.

[Dan Shebunin · Accepted solution]

Well... no answers, so I close my question

[Boris Berenberg]

If the bugs being discovered are similar then they should either be fixed within the parent bug. Or the new bugs should be added to future sprints. Modifying sprints partway through violates the principles of Agile development.

[Dan Shebunin]

But if the fix of one bug (that was included in sprint) also fixed other bug (that was discovered during sprint and has been put in a backlog)?

Unfortunately, our QA is more UI oriented. They could break and twist UI pretty well, but know nothing about how we program our product. They work completely as end-users. So they could not decide for two bugs - are this bugs have one common root from developer's point of view, or not. So they could not say why one bugfix fixed two or more bugs. Conclusion: only developer can decide if fixed bugs relate somehov technically or not.

We are trying a partial solution, that was taken from Atlassian's own scrum boards. When QA will find a bug during testing of developed user story or fixed bug, he will add new special subtask to this bug or story. But only if he decides, that a new bug have close functional relation to tested bug or user story. If he decides, that new bug not so close related - he will create a new bug in backlog. We'll se will it work or not and what would be the impact on sprint duration and delays.

[Infoware_Studios_Jira_Support]

Ok. there is another approach as well. Never log subtasks as bugs. Always log a new bug. The reason is that if you log the new bug as subtask you risk it not being completed in a sprint. Rather use the relates to link. You can also use a workflow step to indicate review needed, then it becomes a new column on your board and is visible. You can then use transition data to report on time spend in the various statusses.

[Dan Shebunin]

Our QA tests a quality of a developer's work in current sprint. QA is a last person, who take part in a user story development process. He set Done status (we have no Prod Owner in our version of Scrum right now) on a user story, confirming that new functionality can be included in distribution. If QA will log the results of his tests as new bugs, which will be fixed in future sprints, does it mean that quality of development of user story is not importan right now? New features have to be distributed as is, without testing?

Your suggestion about new workflow step is very interesting, but it contradicts with your aforementioned suggestion. If new found bugs cannot be included in current sprint, how they appear in Review status? Or you mean, that bugs should be transferred to Review status in backlog and than appear at once in this status in new sprint bypassing Todo?