1

I am a project coordinator in a big team (18 people) for a big project. We have a problem organizing bugs in Jira Cloud. First of all, we have a lot of bugs: on stage, on prod and bugs that come from releases. For now, we organize bugs in Buckets (Epics in Jira Cloud) and within each topic -related Epics we create Buckets assigned to each developer in order to track the time they spend on bug fixing. We also release 5-7 times per week, so there are a lot of bugs.

My question is how better to organize such a huge amount of bugs and get rid of Buckets per person?

We tried to assign bugs to User Stories but our Velocity just jumps which our top management doesn't like.

Thank you for any advice

5
  • 1
    How do you currently organize stories? There is nothing special about bugs, just work that's required. Also, why do you have so many bugs that you need a special form of organization? Are you addressing the root causes of the bugs, to reduce them?
    – Bogdan
    Jan 13 at 19:35
  • Currently, we use Epics, then split an Epic into User Stories. user Stories serve us as technical tasks so people log their time there. We usually don't use subtasks. We have many bugs because we are working on three websites, and the nature of business requires from us to release frequently. I know the current structure is a mess, so I am trying to fix the whole process step by step. I recommended my manager split our team into 3 separate teams, but he was not ready to take the risk. So the biggest pain now is the organization of Bugs. Jan 13 at 22:38
  • I see that you have a your own way of using Jira and your question needs answers within that structure since any outsider answer may hit an issue like “it breaks this report”, etc. I suggest you get a consultant to analyze your Jira and your SDLC to provide you a better solution. Jan 14 at 5:53
  • 1
    @NatalyGinger: I would still say to manage them like the user stories. However, this seems to me like an XY Problem. You should address the reason you have so many bugs. This statement seems to be the issue "the nature of business requires from us to release frequently". If the dev team is not given proper time to do a good job one, you will be doing the same job twice or more by constantly fighting against bugs.
    – Bogdan
    Jan 14 at 12:18
  • Agree on Bogdan. You can kill as many bugs as you want... if they don't stop spamming at a faster rate than you address them, the whole process will fail anyway. It seems you already found the source of the problem (several releases with several bugs). Address this underlying problem and the bugs might decrease.
    – Tiago Cardoso
    Feb 16 at 9:13

1 Answer 1

0

You Can't Fix Your System Just by Refactoring Ticket Management

we have a lot of bugs: on stage, on prod and bugs that come from releases

This is the X in your X/Y problem. You shouldn't really have three buckets of "bugs" for the same issue, unless the issues are environment-specific. Even then, I'd challenge the idea that they are truly separate issues.

Your underlying issue is that gated environments should be conceptualized as a pipeline. For example:

Backlog -> Development -> QA -> Staging -> Production
Backlog <- (all bugs go here)

In other words, it doesn't matter where a bug is found. If it's a bug in the product or service, then it should go back to the start of your loop, whether that's a backlog in Jira or directly to the development team for triage and disposition.

The only "bugs" that really belong to other stages are those that are environment-specific. For example, a gap in the Staging infrastructure itself is something that should usually be fixed in Staging by Staging engineers, not by developers. Even then, I could make an argument for "shifting left" and having infrastructure-as-code developed in Development and then tested in later pipeline stages.

Different Environments May Use Modified Settings

Consider the following, which should be developed and committed in Development but possibly tuned in other environments:

# pseudo-code for per-environment settings
case environment
when dev
  set foo 1
  set bar 1
when qa
  set foo 3
  set bar 2
else
  set foo 5
  set bar 5
end

With software, higher environments may need to tweak settings and use different credentials or data sources, but shouldn't be changing anything fundamental about an application. If they uncover a bug, or a knob they can't twiddle, then that should be reported as a bug to Development. If you have QA, Staging, or Production making fundamental changes to an application, then you're doing the whole thing wrong anyway.

Use Systems Thinking

Regardless of your project management framework, environments should be considered testing gates on your way from "not done" to "done." As such, the fact that you seem to be:

  1. Working off of different backlogs in each environment is a "process smell."
  2. Releasing to higher environments without adequate gate testing is another process smell.
  3. Lacking feature toggles so that you can release often without breaking your build in higher environments is another process smell to consider.

In short, the whole cycle lacks systems thinking. Each department is focused on itself, rather than collaborating together on a holistic CI/CD and testing pipeline that represents a low-friction cohesive process. Focus on fixing that, and the issue of how to represent the work within in your ticketing system will generally become self-evident.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.