What if the business does not see the bugs that you raise?

Questions
#1

Scenario: Sometimes I spot a bug in the testing environment and then I realise it’s actually a live bug. In my opinion, I think it is high priority so I tell my manager. These are live issues that fall under ‘Business as usual support’ rather than development for new tickets.The response from the manager is, there is a workaround for the bug (which is true) so it is not high priority.

Problem: The business was never consulted in this decision and we have a lot of different bugs like that in the backlog.

I wonder how different organisations deal with this.

See my reply below for more details (post 3)

#2

I’m not sure how your team is set up - but the business facing roles (product manager, business analyst) should definitely have input into what your team are working on, whether it’s new features or fixing existing bugs.

How is your workload planned? Do the business roles not get involved in that?

Our team involves a product owner, scrum master and the usual engineering roles. We all have collective input into what our priorities are and this includes discussing bugs.

2 Likes
#3

We usually consult the director or operations manager of the company to talk about fixing existing live bugs (you could say they are the product manager). You can visualise 3 streams of work, support tickets, new feature tickets and bug tickets.

  1. Support tickets are things that are spotted by live users, we have none of those right now.
  2. New features are self explanatory, new things to be added to the system. We have a lot here.
  3. Bug tickets can be a regression or unexpected behaviour (according to the spec).

So in the example of my original post:

  1. I spotted a bug in the testing environment, realised it’s actually an existing live bug which I think is high priority
  2. Consulted IT manager, they deem it as a medium so we do not need to fix it immediately. Bug fix is postponed
  3. The decision was made by IT without the involvement of the business, they are not even aware that this bug exists

Under normal circumstances, there would be meetings every fortnight or so between the scrum master and the product manager. But you can see this was not the case here. Given the workload we’re under to develop these new features, we tend not to pay a lot of attention to live bugs.

Technically, you could say this is not my problem and gets a bit into office politics, but I just wondered if anyone else has the same problem. It feels a bit dodgy to me not involving the business at all, we’re hiding all these away for ourselves ‘If they don’t discover the bug, then it’s not critical’.

#4

I’d agree with you, it does seem odd not to involve the business in these decisions.

I’d also add that I think it’s everyone’s responsibility to try and identify concerns with and aim to improve the team’s process. Does the rest of the team agree with your concerns?

1 Like
#5

At triage time, we look at the likelyhood a bug will cause us damage, and then I look at the severity of the damage. Anything with a workaround that averts damage gets a low impact score. Anything a customer is terribly unlikely to do and can recover from easily also gets a low impact score. If the possible bug impact is terribly low, it’s probably a UX bug, and we know those sometimes just go away in the next version anyway, so I try not bother.

We also look at whether fixing a bug now, will unblock future work, if not, it goes into file 13 (bugs likely to get closed on the next major release).

Jira is a bit broken as a bug tracker because it does not natively differentiate defect priority from it’s damage. But that does not stop me from capturing a bug and then closing it as “wont fix” a day later. It’s not politics to raise defects that you don’t plan to fix, it’s a way of defending against litigation that shows you were diligent, did discover and did chose a course with a context/reason. You still do need to be careful you are not raising bugs that are superficial, or annoyance value.

2 Likes