A question about "Bug" issues

Question

When using the "Bug" issue feature, what the most effective was to use it?

By this I mean if a bug is found in a Story, should the Story be closed out (provided it meets the Definition of Done), or should it be left open until the Bug is corrected/resolved?

Where I work, I am currently seeing it being used to capture Bugs found in a piece of software, but the "Parent" Story is not being closed until the Bug issue has been resolved, which has been over several Sprints in some cases.

I would think that the Story in which it was found (the Parent Story) would be closed out, provided it meets the Definition of Done, and then the Bug would be created to handle the transaction(s) of working the Bug Fix. Am I off track in my thought? Any assistance that you can provide would greatly be appreciated, thank you in advance.

V/R,

Bryan

Marc -Devoteam- · Accepted Answer

Hi @Bryan Henderson

This is a case of process.

What do you define as a process to you consider the Story done if it meets the DoD

If you use testing in the Story (development) and this is part of the DoD and this fails, then I would adhere to raise a Bug and leave the Story open till the Bug is fixed and the Story retested.

If testing is not part of the DoD, then I would expect the Story to be closed and a Bug raised based on testing the is outside of the scope of the DoD.

But these are my 2 cents on the matter.

Bill Sheboy · Accepted Answer

Hi @Bryan Henderson

I respectfully suggest using a team discussion with your scrum master / agile coach and product owner / champion to align on:

* what the group means by "defect",
* how those are triaged,
* how severity and priority work with defects, and
* any definition of done criteria.

That will clarify how to use Jira features, such as the issue type "Bug", to support your team.  (Perhaps include these topic in a team "liftoff" or "re-liftoff" to align on all such team collaboration and quality-supporting concepts.)

The alignment of team members and the courage of the product owner / champion are key...

There could be entrenched stakeholders (on or off the team) who insist all "defects" are addressed before a story moves to completion.  Yet some may ignore severity and priority, or worse still, attempt "design by defect", where they alter scope by writing what they perceive to be a defect.  Those are smells of process defects, such as errors in backlog refinement, sprint planning, focus, delivery practices, etc.

When things like this happen during a sprint, a team retro may help identify root causes and lead to using experiments toward improvement.

Kind regards,
Bill