Forums

By posting to our forums you are agreeing to the Forum terms of use.
Unexpected items during sprints
Last Post 17 Feb 2014 11:07 AM by Charles Bradley. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Mircea
New Member
New Member
Posts:7
Mircea

--
14 Feb 2014 06:22 AM
    Hello,

    My team has the following problem when running Scrum. We have sprints with a 2 weeks length and we establish a Sprint backlog during the planning meeting for each sprint. The problem is that a relatively large number of unexpected high priority items like customer issues are appearing and our product owner wants that these issues to be addressed immediately in the current sprint. Which is the best way to accommodate these unexpected issues in the sprint backlog?

    We considered two options:
    1. Reserve a predefined amount of resources like 20% for these unexpected issues.
    2. To add the unexpected items into the sprint backlog as they are appearing and to remove other lesser priority items with an equivalent size.

    What is Scrum recommending in this case?

    Thanks,

    Mircea
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    14 Feb 2014 07:33 AM
    Hi Mircea

    Reserving a certain percentage of a Sprint is a gamble because, by definition, the demand for unplanned work is indeterminate. If you have a service level agreement with the Product Owner to reserve 20% for this purpose then I dare say it can be made to work, although you'll have to think about how to make it transparent.

    A better option is for the PO and the Development Team to trade items in and out of sprint scope when waste (unplanned work) arises. The MoSCoWing (Must/Should/Could/Won't) of requirements can help here. If you can initially agree that no more than half of the requirements (as measured by story points for example) inducted into a sprint will be Musts, this gives you at least 50% contingency for such trading purposes. The Coulds, and if necessary the Shoulds, may be traded out. It's still a gamble of course, but "up to 50%" is better contingency than 20%. Obviously if less than 50% unplanned work actually does arise during the sprint, then the Should and Could have requirements may be progressed as per the Sprint Plan.

    Whatever percentage you agree on for Must-Haves, it's important to make sure that the stated Sprint Goal depends on these associated mandatory requirements, and not on any Shoulds or Coulds. Failure to do this might result in the sprint being terminated by the PO on the grounds that the goal can no longer be met. In other words the Sprint Goal should be clearly aligned to the Minimum Viable Product for the planned increment of that sprint.

    You are fortunate that it is your Product Owner who wants these issues to be addressed immediately. Often it's a third party, which can make things rather more awkward.
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    14 Feb 2014 06:58 PM

    This discussion may be helpful - http://www.linkedin.com/groupAnswer...entID_null
    Mircea
    New Member
    New Member
    Posts:7
    Mircea

    --
    17 Feb 2014 07:44 AM
    Thanks a lot!
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    17 Feb 2014 11:07 AM
    Mircea,

    As a Scrum Coach, I get asked this question all the time, so I created a chart to help people answer the question.

    http://ScrumCrazy.com/bugs
    You are not authorized to post a reply.


    Feedback