1

Not sure if this has already been discussed, if yes please point me out appropriately.

I am a Product manager in at a software firm. We are developing a mobile application. We are developing 2 features. Now, the client has pointed out a bug. As a Product Manager/Product Owner, how do I handle this situation. We have a team working remotely and another team working in the same location I am working.

Please let me know how to handle this step wise and also if you can give me examples of what you have done. It will be helpful. Any perspective from tech/IT would be super useful.

2

When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this:

  1. Review the bug report and confirm that it truly is a bug. Some people who report issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed.
  2. Assuming that the issue is a bug, check the quality of the report. Is the bug consistently reproducible? If it is, does the bug report have steps to reproduce? If not, is there any indication of how frequent it happens? What is the impact of the bug on end users? What is the difference between actual and expected behavior of the system?
  3. Once the report has sufficient details, it needs to be prioritized. Not all bugs are created equal. For example, a bug that results in data loss is different than one that highlights a spelling mistake, taking two rather extreme cases. A bug that happens consistently and repeatedly is different than one that is intermittent. A bug with a known workaround is different than one with no known workarounds, and the level of effort to execute the workaround also matters. In an ideal world, all bugs would be prioritized over new features, but this isn't always achievable.
  4. Once a bug has been prioritized, it will eventually come up with a development team. They can make sure that it's understood, clear, and that they have any information that they need to investigate, implement, and fix. As the development team learns more, there may be various options and ways to either fix the bug or mitigate problems. This can possibly spawn new work and it's up to the development team and product manager to understand the risk and impact of various options.

As the product manager, you should be communicating with stakeholders - customers, end users, technical support staff - to make sure that the right people have the right visibility into the status of the issue. This can also help you understand the stakeholder impact of not addressing the issue - priorities can change over time based on how the manifestation of the bug is also changing.

  • You say - Once the report has sufficient details, it needs to be prioritized. For prioritization, I would again groom the PB for the upcoming sprint right? I will give higher weightage to the bug and ask the dev team to fix in the next sprint. – SPO Nov 13 at 1:50
  • Hypothetical question – lets say the client points out a bug which is extremely critical – say they aren’t able to use the application because of the bug. In an agile world, can you EVER ask your dev team (maybe 1 or 2 engineers depending on the effort to fix the bug) to stop their current task and then fix the bug. Again assume that you have exhausted the buffer as well. What would be the scenario where bugs aren’t prioritized over feature development? – SPO Nov 13 at 1:50
  • @SPO A bug fix doesn't need to be ordered for the next Sprint. A very critical issue could result in being prioritized over existing, planned Sprint work. In this case, though, I'd also want to invest additional time to figure out how such a critical bug made it through refinement, development, and testing. Other bugs could wait 2, 3, or even more Sprints before it comes up for development. I prefer to prioritize known bugs sooner rather than later, but this is a business decision. Is it more valuable to invest the time to fix the bug or deliver a new feature? – Thomas Owens Nov 13 at 11:12
  • when you get a bug say belonging to either MAJOR or MODERATE. Do I put them in Product Backlog? SO that during sprint planning I can create sprint backlog based off discussions with the development team and what we need to achieve in that sprint. So a MAJOR would be prioritized high in the sprint backlog list. Sometimes a bug (though marked as MODERATE OR anything else) can be a new feature req. I as a PO may not be able to say that in confidence however when the dev team look into the bug they can probably help get more clarity. Do you think my approach is correct? – SPO Nov 13 at 23:24
  • @SPO Those are questions that you need to figure out the right answer to. What does "major" or "moderate" mean to your team and organization? How do you determine the value of fixing a defect versus introducing a new feature? There are no rules here. If you're a Product Manager, you need to be able to make these decisions to best represent the various stakeholder to your team(s). – Thomas Owens Nov 14 at 2:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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