How to manage production bugs or support tickets bugs in scrum when we are managing Bugs with task and not as requirements.
Hi,
I'm using Azure DevOps for managing scrum in my organization.
In that for managing bugs, I have kept the option as bugs should be managed with tasks, it means bugs will be managed in Task Board rather than Product Backlog Board.
In that case whenever QA found any bugs in any backlog items committed in a sprint then they can able to create bugs against PBI in Task Board itself and that's sound good but I m facing problems in handling Bugs that are coming from other sources like production bug, Support Tickets, etc which are not related to committed Sprint Backlogs.
So, in that case, I cant put that bugs in the sprint task board and I have to put them in the product backlog.
Now my problem is how I will put bugs in the product backlog as we have set up bug configuration as managing bugs with a Task so now how I can put bugs in the product backlog as a requirement?
One option I have is to create PBI for the bugs as work item type PBI rather work item type bug in product backlogs, whether this solution is standard based on the scrum fundamentals?
Please help me to get the solution
https://www.scrum.org/forum/scrum-forum/55784/can-you-pull-bug-active-s… among many other posts.
I'm using Azure DevOps for managing scrum in my organization.
I'll bet you aren't. The people in a self-organizing Scrum Team will manage their own work.
whenever QA found any bugs in any backlog items committed in a sprint
They'll also recognize that backlog items make a poor commitment.
Unfortunately sometimes people have a tool which constrains their thinking and clouds transparency:
- the "bugs" you describe are not addressed by a tool at all but by a Definition of Done, which would be a sensible thing to commit to.
- The Product Backlog ought to tell the truth at all times about how much work remains for the Product, including any rework or fixes to be planned into future Sprints.
- During a Sprint, any rework needed for a Done increment that meets the Sprint Goal will be added to the Sprint Backlog.
One option I have is to create PBI for the bugs as work item type PBI rather work item type bug in product backlogs
If there's a "bug", it means that some work in the Product Backlog was not Done at all. It's still there and remains to be Done. That's the truth to be told.
Stop getting caught up in the words used to describe an item. Product Backlog Items have value. The value is negative as long as they are satisfied, positive once they are satisfied. Now, consider new features and bugs. Does that statement hold true? The Scrum Guide states this.
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
Will the product improve if you correct a bug? Yes, it will.
If a defect is found in the product that is available in your production environment, an opportunity to improve the product has been discovered. Create an item for it in the Product Backlog that is the same item type that would describe a new feature. Remember that they both provide positive value when completed.
I would not change how you handle your bugs found in code changed during a Sprint. Those are preventing you from being Done. Fix them during the Sprint as a task.
I know organization handle things differently, but in general I would say that If the DEV team needs to do something to make the product better, than is it fine to be on the Product Backlog.
In my world, production takes priority. So, when we get an issue/bug that is in production, and it requires scrum team effort, we had a JIRA Defect (specific to JIRA but you get the point). If it is something that needs addressed NOW, then we may add to current sprint backlog. I can explain the metric impacts because it was the right thing to do.
To answer you questions - we manage all items in one backlog, but we do label then differently depending on what it is.