Who can we keep productive planning meetings when the backlog is composed mostly from bugs?
Hello,
I encounter the following problem. We are running two weeks sprints to improve a legacy product. Our backlog is consisting mostly from bugs. In each sprint the team selects around 30 bugs that are addressed.
The problem is that having so many items does not promote collaboration. The team has 6 members and each one have some information about some bugs at best. That is because the team members are familiar with some parts of the product but no one with the entire product.
Most bugs require investigation and we don't know how much time will take to investigate upfront. If the cause is found then the fixing is usually easy.
The planning meeting starts to become boring because when one member presents about a bug the rest of the Development team has almost no context and cannot provide too much help.
In order to improve I decided to keep the meeting offline by having people collaborating to estimate the bugs during the first day of the sprint and keeping a short one hour meeting to establish a content for the sprint and a plan for the next few days.
Any ideas to keep it better?
Thanks,
Mircea
> In each sprint the team selects around 30 bugs that are addressed.
What criteria are they using to make the selection? is there an overarching Sprint Goal for the increment...one which the Product Owner values and which the whole team can buy into?
Hi Mircea,
Where is the Product Owner during the Sprint Planning meeting?
One of points with team sprint planning is to take advantage of wisdom of the crowd to come up with creative ways to implement a given function/feature. In this case you are not looking to be creative, the PO just want to kill the bugs.
As you say, most bugs are often very hard to estimate. Most time will probably be spent on investigating the origin of the bug and when you have found that, the time to fix it is usually very small. Consider pairing to share the knowledge of the system between developers and maybe just track the number of bugs fixed per sprint and then simply take on as many as you historically managed to resolve in each sprint. You don't want to spend time in sprint planning if it seems wasteful, just have the PO present the most prioritized bugs to fix.
Yep, I agree with Fredik on pair programming. Do you guys do the grooming sessions or directly goes into sprint planning?
Cheers
Sanjay
Hi,
The bugs are selected according with a priority set by product owner. The product owner gives an order to the items (mostly bugs) from product backlog and the Development team selects items from the top of the list during the planning meeting. The sprint goal can be something like "Reach 85% pass rate on the set of tests X devised by the QA team." or "Reach code freeeze (0 bugs) on feature Y".
Thanks,
Mircea
Hi,
Product Owner is present during the planning meeting and we are constantly grooming the product backlog. But for a bug, going into details means usually to fix it.
Thanks,
Mircea
> The sprint goal can be something like "Reach 85% pass rate on the set of tests
> X devised by the QA team." or "Reach code freeeze (0 bugs) on feature Y".
These are technical criteria that might be appropriate for incorporation into the Definition of Done for a sprint. However, they do not represent a functional "coherence" that the selected PBI's should represent in aggregate. The Scrum Guide explains the importance of having such a coherence and why it is essential to a Sprint Goal.
Fixing bugs within a particular feature, and which thereby allows the associated business value to be released, might be an appropriate example of a coherent goal for defect handling. Without a Sprint Goal that the whole team can buy into we cannot expect them to collaborate towards the delivery of a meaningful increment. That seems to be the problem here.