Back to Forum

Bug Prioritization

Last post 04:51 pm November 14, 2019 by Sally SPO
2 replies
Sally SPO
09:44 pm November 13, 2019

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. 

Ian Mitchell
02:02 am November 14, 2019

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.

 

Sally SPO
04:15 am November 14, 2019

Great points Ian. Helped me change perspective

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.