This is one of those questions which comes up again and again. And it came up last week when I visited a client’s offices – yes I actually visited a client! The answer to this question is, as often happens: It depends. So let me give you my thinking.
First, many teams have a rule that work must be scheduled in the sprint planning meeting, after which this is fixed. Teams have a right to make this rule. So, if this is a team rule – what Kanban folk call a policy – then work is not allowed in.
This rule is based on a strict interpretation of Scrum. The thinking – particularly in early implementations of Scrum – was that changing priorities was a big problem for teams and therefore fixing the work to be done for a few weeks made sense.
In the event of that things did change, the team would declare an “abnormal termination of sprint” and move to start a new sprint with new priorities.
Now, for some teams this makes complete sense. Barring work from entering the sprint after planning makes complete sense. Equally it makes sense for team members to only do work scheduled in the sprint and refuse all other work.
So, it depends… when a team is troubled by new work appearing or by priorities changing, and when a team is expected to deliver something new – when their overarching priority is not support but building something new – then this approach makes complete sense.
But do not follow this rule just because you think Scrum says so. I just had a quick look at the latest Scrum Guide; it does not actually mention abnormal termination of sprint. It does say “No changes are made that would endanger the Sprint Goal,” which then leads us into a conversation about the sprint goal; but let’s hold that for now.
Now ring-fencing the team and the sprint like this solves one set of problems, but it creates another set. If the team is aiming to be reactive, why would they not pick up work?
And as teams increasingly become DevOps, SecDevOps, BizDev or whatever, things get more complicated. It would be irresponsible to hold a “no work enters the sprint” if the live server was down or a security hole had been found!
But at the same time, being hyper-reactive has a downside because the team would be constantly distracted.
Ultimately it is the Product Owner who should have the final say on whether unplanned work is accepted or not; but when you have a customer on the phone, someone else may be forced into a decision.
I apply two tests: First, is the unplanned work really urgent? – or could it wait a few days and be considered in the next sprint (or even queued in the backlog for longer).
Second, is the unplanned work valuable? – namely, is it more valuable than the work the team is doing and would be displaced by this work. Ideally, it would be valuable enough to justify the disruption it causes by late entry, too.
Hence, I would like to talk about urgent but valuable unplanned work. Just because something appears after the sprint planning, it does not mean it is not valuable. If the work is urgent, and if it is valuable enough, then it deserves to enter the sprint and get done.
However, I would like to build in two feedback loops.
First, as the work arises, does the person raising the work understand the disruption this will cause? Are they prepared to accept that some other work may not get done?
I like to make this real: pull up your board and show the requester the consequences. Let them prioritize the work against the current planned work. This can make the unplanned work go away.
Second, mark the late-breaking work so you can track it through the system – on a physical board I would use a yellow card. At the end of the sprint review how many yellow cards you have and talk about whether the right decision was made.
Over time, as you build up your data – and stock of done yellow cards – you can reason about the cards and decide your long-term action.
For example, you might want to make an allowance in sprint planning for unplanned work: suppose your team averages 3 yellow cards a sprint, then, when you are planning the sprint allow space for them.
If you have many yellow cards regularly you might even want to move to a Kanban model or split the team.
Review the requests: what are the common themes? – is there a module which is particularly troublesome? Would some remedial work help reduce the unplanned work?
Or is there someone in particular who raises unplanned work? Should the team leaders talk to this person and see if they could change their behaviour? Perhaps they could make their requests a few days earlier.
Maybe you want to ring-fence a team member to deal with unplanned work while the rest of the team pushes on with the main work.
As I said at the beginning, the unplanned work question comes up a lot. I discussed it in my book “Xanpan: Team Centric Agile Software Development.” So, if you want more examples, check it out. And if you have any other suggestions please comment on this post.
I am Allan Kelly and these are my agile-thoughts
2021 © London, England, UNITED KINGDOM by Allan Kelly
Allan Kelly wants software professionals to enjoy more fulfilling and satisfying work. He advises teams and managers on using Agile approaches to improve the way work is organised and requests are made.
Happier people and better ways of working make for more effective companies, greater value and competitive advantage.
Despite being dyslexic his desire to change the world has led him to write seven books such as “Business Patterns for Software Developers” and “Continuous Digital.”
“Succeeding with OKRs in Agile” is his latest one.
USEFUL? You can share it!