Question : If the product backlogs has huge bugs count, should we estimate the bugs

Question

Hi all,

Here is the illustration of the problem.

Our client is legacy company and they have few hundred bugs in the product backlog. They also new story as part of the product backlog.

And some of those bugs has "highest"  priority.

So the PO and scrum team, agree to fix "X"  number of bugs and "Y"  number of stories in each sprint.

And the release of the next version is done every quarter (not after  each sprint).

The method (or units) of estimation is # of person-days.

They have not estimated the bugs , while the " Fix version number is assigned to the bug" (Fix means target version). But without having the estimate it is becoming difficult to predict the "scope / content"  of the next release. Upper management would like to know , how many defects will be "released"  while the next version is delivered to the clients.

So the question is :

Shall we do estimates for the bugs (efforts in person-days)  ?  OR don't estimate for bugs?

John Funk · Accepted Answer

Hi Dipak,

in my opinion you only need to estimate those that you think might do this sprint and maybe a handful of others. Otherwise you are wasting effort.

Jack Brickey · Accepted Answer

I think this is more of a discussion than question as there is really not "right" solution, just the one that works for you.

I have used the following approaches:

* Discuss w/ your team to come up w/ a "Bug Backlog Reduction Commitment", e.g.  "reducing the bug backlog by 50% in 90d". Then create "Bug Reduction" stories for each sprint/user reserving say 1d of effort or whatever you need to meet the larger commitment. Allow the team to draw down from the bugs to resolve them during the sprint and link them to the story once they are complete. In this model you do not add the bugs to the Sprint but you do account for the work. You also are giving the developer the accountability to manage their bugs, but watch out for bottom feeding - developers working a bunch of easy low priorities vs. the bad boys.
* Create a bug Kanban board to manage the backlog. Rank them and during the sprint planning also review the bug board and add the sprint value to those you wish to commit to and include the OE for each. Work them as you would any story.

Either way, if you wish to be serious about beating down the bug backlog you need to account for it and set expectations for each developer. Discuss w/ your team to see what works best for them.