A question about "Bug" issues

[Bryan Henderson]

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 solution]

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.

[Bryan Henderson]

Marc,

Thank you for your response, we use separate Tasks to handle the testing portion of development, which is more in-depth testing by a "User", well beyond functional testing done by the developer. 

Regards,

Bryan

[Bill Sheboy · Accepted solution]

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

[Bryan Henderson]

Understood, I am planning to do just that; however, I will need the support of my management with this. One problem is that no one where I work actually knows what a Scrum Master is or does and they all have their own misconceptions of it.

I am a Registered Scrum Master, and an Agile Coach, the only problem that I face with my coworkers is that I am not a software developer and have just been thrust into the position without the others knowing that I actually know what I am talking about, I am fairly new to being a Scrum Master and an Agile Coach as I have only been doing this role for about two years in another organization, although my coworkers have all been through the class that I facilitated with a few other Registered Scrum Maters/Agile Coaches. 

Another problem that I face is that the teams that I need to convince are still stuck on the "Waterfall Method" of software development and view Agile and Scrum as a passing phase. So, it is a little difficult to convince the others that when the Definition of Done has been met, it is time to stop and move on. They will need to close out the Story and write a Bug Fix to cover the transaction of fixing the software, close that out when completed, then create a Task to cover that testing phase that ensures the Bug has been corrected. They have all been using (misusing) Jira for several years, while I have only had the opportunity to use it for about 8 months (with no training or any other exposure). They also consider themselves the experts on all things Jira and Scrum related. 

So, yeah, I have a little bit of work to do to get all these people to understand and be on the same page, but it is really difficult to do as this is not my primary job. I am also a Product Owner of my Scrum Team (another misconception of the role by my coworkers) in addition to other tasking (I wear many hats at work). But I will take it one step at a time and try to change their minds.

Thank you for your response.

V/R,

Bryan