2

I have a disagreement with the dev team lead over whether a P0 bug has to be on the production server or not.

We are using JIRA as bug tracking system, and I've found this bug on another team's environment, but it's related to my team's module. I've informed the other team's lead developer, the team's QA. They stated that this issue is not related to their work, so I reported the problem as a bug on my team's JIRA board.

So it's now the responsibility of the developers in my team, but my team's lead developer believes that P0 is for production bugs only, and this bug has no priority for now.

How do I resolve the disagreement?

Improve this question

5 Answers 5

Reset to default
4

As others have said, if there isn't a consistent definition of what constitutes top priority across all teams, there will be disagreement over what constitutes a top priority bug.

That said, I have a few thoughts to offer:

  • Will this bug break core functionality if it is introduced to production? If the answer is "yes" then priority should be higher.
  • Does this bug have a workaround that an end-user can employ? If the answer is "yes", then priority should be lower.
  • Does this bug occur in a high-traffic or high-visibility part of the application? If the answer is "yes", then priority should be higher (even if it's just a spelling mistake: presentation bugs lead users to think the software is lower quality because if the developers "don't care" about presentation, what else don't they care about? - perceptions matter a lot in this field).
  • What is the severity and probability of the bug? A severe bug (say, one that wipes user profiles) that is highly likely to occur will have a much higher priority than an equally severe bug that's very unlikely to occur.
  • How soon does your team plan to release the functionality that's related to the bug? If you're planning on releasing soon, that will increase the priority of the bug.

I'd suggest that you document all these factors, then discuss the bug with your lead developer to come up with a mutually agreed-on priority. It's possible that even if this is an application breaking bug it won't occur in the production environment (I've seen those, and they do get a much lower priority because they don't go to production. I've also seen situations where something works perfectly in the development and test environments but is broken in production).

Improve this answer
1
  • Yes. The bug categorizations do not exist in isolation -- they exist as a shorthand for a longer conversation about how you want to manage your software lifecycle. It may be fine to define P0 to mean "found a production server", but everyone with a stake in the outcome should agree about that.
    – user246
    Feb 26, 2015 at 20:14
3

You need to take a step back and look at the whole picture- why did the dev lead objected to the P0 setting ?

It is not because "it is not in production" (well, it is but there is a higher level reason for that) but because the company doesn't have an agreed and accepted definition for priority levels across all teams.

Improve this answer
1

Recently, I found a P0 bug in the pre-production environment. I am the lead QA and I refused the deployment in production before correction.

The bug made a simple action not work (classical one, used by every single person of my company each day). The priority of a bug is not due to where or how it is found, but the severity and the effect of the bug.

In my team, when a bug blocks an action, but there is another way to do the action, the bug is judged less urgent.

Improve this answer
1
  • the problem is, it was't my release so it's hard to take suck an action, the best thing to do is inform the other team members - QA & dev- which i did, but the bug is related to us this is why I've posted on our board, do you think there is another action that i should take?
    – user6336
    Feb 25, 2015 at 7:53
1

Apparently, in your company there are at least two teams. Your team needs some functionality from application, and the other team is responsible to deliver it.

Priority is just a meaningless category to prioritize work globally. You can set your own priorities as needed inside your team.

You tried to ask for help from other team. Seems that help is not coming. You need to ask your own developers, how hard it will be to find out where bug is, how to fix it, and if they will be allowed to patch the fix (or some process rules will prevent that).

If your team can fix the bug easily, do so. Doing so you will help the other team which seems to be swamped. Tell them you are doing it to help them.

If your team cannot fix it easily (will take too long to understand the area to make fix safe, and other team already understands that area well, so it will not be efficient use of your team time), manager of your team needs to talk to manager of the other team. Maybe your team can do something else to help the other team to get time to fix your bug.

If all else fails, both managers have boss, and your manager can escalate it up.

If your bug is crucial to you, but irrelevant to users, it might be that it will not be fixed anytime soon. Develop workaround and checklist to contain it.

P0 or not, it is all about triage and fixing most important bugs first, and finding who has the capacity to fix the bug right way.

Improve this answer
1

Our highest bug priority is called "system failure". So if a bug crashes the server or makes the whole application unuseable, like you cant login anymore, we use this priority.

For this its regardless if the bug occures on beta, pre oder live. But such bugs are normally visible in early development.

Bugs which onnly "crashes" parts of the application are not allowed to get the highest priority. Furthermote as already set the priority also depends on if theres a workaround.

So I would say the first step to answer this question is to think about if the highest priority has further meaning like in our project.

Improve this answer

Your Answer

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

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