'Business As Usual (BAU) support' and the Sprint Goal...
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?
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?
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.
Thanks for the response Ian! That helps.
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
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.
Agree with all the above.
In addition, I guess it also helps team when we reflect them the reality of the % split between Planned, Unplanned work and BAU. Has anyone here have examples to share from their engagements on how did teams agree to track these categories of work?
I am no way advocating tracking, managing etc. But building a good metric that helps team show the mirror (and not singling out individuals) is always useful to share with Product Owner and above on what's happening and how a teams' ability to deliver true customer value is being impacted with all these adhoc requests.
Recommendations?
I have things that I track but never share with anyone. Everything I track I use for my own ability to identify trends, activities that impact the team's cohesion and potential to produce, whether negatively or positively. I use this information to guide my coaching of the team.
If someone other than me wants information of this kind, I usually ask them for the specific reason they want it. If it is something I feel is justified within the Framework I will work with them to identify a mechanism for it. But remember that the primary measure of success in Scrum is to determine whether the Scrum Team is consistently delivering value.
In your example and in the original question, I feel this boils down to respecting the Product Owner to be making the correct decisions on what work will allow the Development Team to deliver the most value. It covers the Development Team honoring the Product Owner's decisions but being completely transparent on how those decisions impact the decisions that the Development Team made about the contents and goal of their Sprint.
That transparency and respect is the best metric for "tracking" this activity. If the team is consistently failing to deliver the value that they forecast to deliver in Sprints then you have an indicator that something might be interfering (i.e. impediment identified) During Retrospective discuss this, identify the problem and come up with modifications to behavior that could improve the situation.