Forums

By posting to our forums you are agreeing to the Forum terms of use.
'Business As Usual (BAU) support' and the Sprint Goal...
Last Post 31 Aug 2013 12:29 AM by Ian Mitchell. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Senthil
New Member
New Member
Posts:7
Senthil

--
29 Aug 2013 02:16 PM
    During a particular Sprint, if there is a support required for the product (a critical defect for example) that is already in Production, how does the Sprint Goal that was already set gets impacted. My understanding was that the Product Owner adds that defect to the current Sprint and requests Developers to get it fixed. But it would really nice how the Sprint Backlog that was planned for that specific Sprint gets adjusted?
    Senthil
    New Member
    New Member
    Posts:7
    Senthil

    --
    29 Aug 2013 02:20 PM

    Posted By Senthil on 29 Aug 2013 03:16 PM
    During a particular Sprint, if there is a support required for the product (a critical defect for example) that is already in Production, how does the Sprint Goal that was already set gets impacted. My understanding was that the Product Owner adds that defect to the current Sprint and requests Developers to get it fixed. But it would really nice to know how the Sprint Backlog that was planned for that specific Sprint gets adjusted?

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    29 Aug 2013 09:46 PM
    The PO can ask the Development Team to action unplanned work, but it is up to them whether or not to add it to the Sprint Backlog, and therefore to the current Sprint. The PO can't add anything to the current Sprint without their agreement. The Development Team wholly own their Sprint Backlog.

    The Development Team must explain the likely impact of unplanned work on the Sprint Goal. It's quite plausible that it will mean the Goal will not be met. The important thing is to make sure the PO is appraised of the risks so he or she can make informed decisions.
    Senthil
    New Member
    New Member
    Posts:7
    Senthil

    --
    30 Aug 2013 01:03 PM
    Thanks for the response Ian! That helps.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    30 Aug 2013 03:28 PM
    In our Scrum.org courses, we teach the following re: bugs found in already delivered functionality:

    Fix the bug if it is critical or easily fixed. Otherwise, put the new bug into the Product Backlog to be ordered and fixed in an upcoming Sprint.

    I coach something fairly consistent with the above, along these lines:
    http://www.ScrumCrazy.com/bugs
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    31 Aug 2013 12:29 AM
    Hi Charles

    What you say about the scrum.org course surprises me a bit.

    If the teaching is to action bugs if they are critical or easily fixed, or otherwise add them to the Product Backlog, that means the Quality of Service of work items is permitted to vary. I'd have said that's a Lean Kanban philosophy, but not a Scrum one.

    In essence, it amounts to having a "fast track lane" on the Scrum board - the sort of QoS variation that is found in most "Scrumban" implementations.

    Please note: I'm not suggesting that this teaching is bad or wrong. I'm just surprised to learn it's expressly supported.
    You are not authorized to post a reply.


    Feedback