'Business As Usual (BAU) support' and the Sprint Goal...

Last post 01:29 am August 31, 2013
by Ian Mitchell
5 replies
Author
Messages
03:16 pm August 29, 2013

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?

03:20 pm August 29, 2013

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?

10:46 pm August 29, 2013

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.

02:03 pm August 30, 2013

Thanks for the response Ian! That helps.

04:28 pm August 30, 2013

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

01:29 am August 31, 2013

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.