Hi - needed some advice on how I can best go about "bug" situation I am in.
I am a new PO and have a team both in USA and India. We have a bug that is come in. I am slightly confused on how to go about this process. Please correct me if I am wrong with my thought process.
1. I have triaged the bug. Tried to replicate it per my initial conversations with the client. I have noted all the details.
As a PO, I am aware I need to prioritize the bug based on severity, impact and probablity of occurance/reoccurance. In our company, we have 4 severity levels.
S1: Broken, highly critical
S2: Major - something should work as written in use case but isnt
S3: Minor/Moderate: product/functionality must work as intended but doesnt work or never did
S4: Low: Generic or cosmetic changes like spelling, alignment and so on....
Per my conversation with my client and triaging, the bug is a S3 level bug.
How do I go about prioritizing? What I mean by prioritizing is to look into this bug in the next sprint by putting in product backlog. I know many times things that are logged as BUGS are NEW FEATURE REQS or CHANGE REQ. How do I figure if this S3 bug is indeed a bug or a new feature req. I am confused where I need to involve my developers (who can be QA folks at times).
I will be glad if I can get some guidance about this.
How do I figure if this S3 bug is indeed a bug or a new feature req.
Regardless of how you categorize it, isn’t it just work which remains to be “Done” and which should be ordered on the Product Backlog on that basis?
I am confused where I need to involve my developers (who can be QA folks at times).
Shouldn’t they be involved in Product Backlog refinement, and Scrum events such as the Sprint Review? Why not collaborate with them every day?
If work is discovered which the team consider to be a defect, they may wish to improve their Definition of Done to prevent reoccurrence.
Great points Ian. Helped me change perspective