Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Who can we keep productive planning meetings when the backlog is composed mostly from bugs?
Last Post 26 Feb 2014 01:50 AM by Ian Mitchell. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Mircea Cezar Preda
New Member
New Member
Posts:13
Mircea Cezar Preda

--
25 Feb 2014 06:49 AM
    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

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1676
    Ian Mitchell

    --
    25 Feb 2014 07:16 AM
    > 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?
    Joshua Partogi
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    25 Feb 2014 08:51 AM
    Hi Mircea,

    Where is the Product Owner during the Sprint Planning meeting?
    Fredrik Vestin
    New Member
    New Member
    Posts:85
    Fredrik Vestin

    --
    25 Feb 2014 09:05 AM
    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.
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:156
    Sanjay Saini

    --
    25 Feb 2014 07:12 PM

    Yep, I agree with Fredik on pair programming. Do you guys do the grooming sessions or directly goes into sprint planning?

    Cheers
    Sanjay
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    26 Feb 2014 12:11 AM
    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
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    26 Feb 2014 12:15 AM
    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
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1676
    Ian Mitchell

    --
    26 Feb 2014 01:50 AM
    > 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.
    You are not authorized to post a reply.


    Feedback