How to deal with unavoidable on-demand tasks in Scrum? Or should we even try?

Question

I was put in charge of implementing Scrum in my Development Team. Unfortunately, the company I work with has a rather stale structure that does not go well with this framework. The team works on a project that several other teams use/depend on. Besides our own goals we have unexpected feature, integration, support or bugfix requests. Some of them can be filed in the Backlog and wait for their turn, but some absolutely have to be handled ASAP, or "in real time" as one of our clients put it.

The situation is far from ideal and I as the Scrum Master do not have the power to protect the Team from this kind of work. I am trying to make the best that I can from the situation we found ourselves in and get as much out of Scrum as possible.

My first question is: how to handle these kinds of requests within the Scrum framework?

I am not a fan of having a separate "request bucket" User Story - it either covers up the amount of work that was done or artificially increases the velocity.

Does manipulating the Sprint Backlog in such a broad scope make any sense? Sometimes we would have to move more than a half of our current Sprint Backlog back into Product Backlog to make room for all the on-demand requests.

Perhaps my initial question should be replaced with - is there a way to handle this kind of situation within the Scrum framework?

If there is no way to do it in a reasonable manner - are there any other Agile frameworks that could be of help?

Answer 1

Retrospect, retrospect, and retrospect some more. While the problem you describe exists to varying degrees on most scrum teams, don't settle with a band-aid solution. First understand, quantify, and make transparent the impact to your scrum team. Sometimes its better to do this without applying a pain killer...

Creating slack, whether via velocity or capacity based planning is not a true solution, just a reaction/painkiller to lessen a problem that may initially seem too external to address.

As a scrum master you should feel empowered to tackle deep and/or long-term organizational problems outside of the immediate team(s) you serve. Why do so many ad-hoc requests come in? Is there a pattern, organizational structure(s), or certain people that agitate the issue? Use the retrospectives with your team combined with your time spent navigating and understanding the organization to get at the real root causes of why the problem arises.

Ashok provides one solution for the deeper problem - which sounds like a lack of higher level planning and coordination between teams. How you solve that problem will depend on your organizational structure and the root causes you identify.

Answer 2

I recently experienced exactly the same situation you are describing. While I'm not the Scrum Master for my team, I was the only person on the team who had used any Scrum methods previously. To solve the issue of things coming up and derailing the Sprint plan, we adopted a method we call 'The Batman' which, after some tweaking, has really worked for us.

Every week, one developer is 'The Batman'. They do not complete any Sprint tasks, but are instead made available to do 'whatever work comes up', all of those bug fixes, sudden requests, and "things that must be done now please". While the person who is Batman changes every week, there is always a 'Batman' available for general requests. Our small team rotates through a list, such that each developer spends one week as The Batman, and then two weeks focused on Sprint tasks. We identify the Batman by literally placing a Batman figurine on the desk of the individual filling the role. This makes it very easy for co-workers to correctly identify who is available to help them. Any person may approach the Batman and describe their problem or request. The Batman then makes a decision to either a) identify the task as something non-urgent and place it in the backlog or b) add it to their list and work on it at their next opportunity.

In the (unlikely) event that no such requests exist, The Batman can grab from the backlog for small tasks, or attend to code cleaning/documentation/other things that tend to get neglected. Any tasks the Batman performs still results in a tickets being created in our ticket system, and is 'pulled into Sprint' so that we can track the work, however we assign all 'Batman' tickets a zero story point value. This is because we do not count Batman tasks in our Sprint estimations. We use JIRA for our ticketing system, and while our 'Scope Change' chart shows disappointingly high values, ultimately it does not negatively affect our estimation or sprint planning. By putting a label on 'BatTasks', and assigning them zero story points, it makes it easy to determine what was from the original sprint and what was pulled in by the Batman.

Our Sprints last for two weeks, so in the event that the Batman is a particularly prolific developer, we do not harm the Sprint by making them inaccessible for the entire Sprint. We also found that a solid week of bouncing around handling random quick requests is about as much as we can handle at a time before returning to the comfort and structure of Sprint work. It is also critical that when a Batman's time is up, they must cease work on their Batman tasks and hand over a full description of any incomplete tasks. This goes the same way for a Sprint worker transitioning to Batman - they need to be able to quickly hand off any tasks they were working on. Critical to this is having good documentation on your work as you work, and I think that as a team our in-task documentation skills and ability to hand off tasks quickly to another developer is improving. This is a great skill also for someone who is going on vacation, becomes unexpectedly ill, etc.

Another advantage we found is that co-workers are now interrupting only one individual, and not side-tracking any developers who are focused on Sprint tasks.

We also tried some unsuccessful variants of this approach. We tried having one 'Batman' one day a week (it was not enough) and tried having the entire development team act as 'Batman' one day a week (also not enough). Due to the frequency of requests that came through, we found that always having a 'Batman' on call worked well for our team. What is important is that we gave each attempt a try, and continued to tweak the process to our needs before giving up.

An idea we have considered was also assigning a 'Robin', who would work on Sprint tasks, but if necessary, could be called upon by Batman to help out if the load got to be too great. We have not tried this approach yet, but I like the idea of it.

One interesting side affect of this approach is that the Batman ends up getting exposed to many different aspects of our system. As a team, it has greatly increased everyones general knowledge about the code base, and is helping us all become better acquainted with areas of our code that we did not necessarily have exposure to before.

Answer 3

If these kinds of interruptions are truly unavoidable, my advice is to have the team plan and allow time for them. During the sprint planning meeting, each team member should calculate their capacity (in hours) for the new sprint. If you know or can calculate the amount of time that the team spends on other work, then subtract that from the capacity. Or, instead of planning to 100% capacity, try planning to a lower capacity (can be different for each team member based on how often they get pulled into other work) knowing that if interruptions don't come the team can always pull in additional user stories.

Answer 4

Get the other teams to do Rolling Lookahead Planning

Some type of work such as production bugs cannot be planned for and can only be handled the way @JillSanderson suggested.

However, you also seem to have other urgent work coming your way:

The team works on a project that several other teams use/depend on.

This type of work can be planned for. Just that your team is not in the loop until late in the cycle. Your Product Owner (PO) should continually work with the other teams to identify any work that they plan to send your way. In due course he/she should strive to convince the other teams to do Rolling Lookahead Planning:

• Once the current iteration has been planned, the team remains in the iteration planning meeting and plans two more iterations...
• the second and third iterations are planned at the user story or product backlog item level rather than with tasks...
• The chief purpose of rolling lookahead planning is the coordination of work to be done by multiple teams. As new iterations roll into the planning horizon, teams look ahead to the functionality likely to be developed in those iterations. In doing so, teams on a large project are likely to find dependencies upon one another.

Answer 5

Although, almost all the ways to solve your problem were already described, I have decided to write my answer to add a little bit of organization and references.

Henrik Kniberg in his "Scrum and XP from the Trenches" book describes four typical actions for solving your problem:

“Too many external disturbances”

Typical actions:

• ask the team to reduce their focus factor next sprint, so that they have a more realistic plan.

• ask the team to record disturbances better next sprint. Who disturbed, how long it took. Will make it easier to solve the problem later.

• ask the team to try to funnel all disturbances to the scrum master or product owner.

• ask the team to designate one person as “goalkeeper”, all disturbances are routed to him, so that the rest of the team can focus. Could be the Scrum master or a rotating position.

---

Let's take a look at these options:

• Ask the team to reduce their focus factor next sprint, so that they have a more realistic plan.

  It's the same as @JillSanderson answer. But, in my opinion, it's better to use focus-factor instead of reducing capacity. It gives absolutely the same effect (reduced velocity), but it's more logical.

  "Focus factor is an estimate of how focused the team is." More unexpected "external" tasks means less focus factor. So, you should consider the focus factor in the Sprint Forecast.

  This approach has one limitation. The focus factor (amount of "external" tasks) should be approximately the same. Otherwise, the forecast of the number tasks in Sprint becomes meaningless.

• Ask the team to record disturbances better next sprint. Who disturbed, how long it took. Will make it easier to solve the problem later.

  It's almost the same as @WBW answer. Gather all needed information during Sprints, analyze it during retrospectives, find root of problems and try to eliminate it. Maybe you should increase quality of code with special engineering practices (or improve testing) to not spend such a lot of time on bug fixing. Or, maybe you should delegate some work to another team. Or improve planning for reducing the amount of unexpected features from the customer. Or something else. It is hard to give concrete advice, because it depends on many factors. It's your job as Team Lead to find and fix these problems.

  The main limitation of this approach is that eliminating the roots of some problems is not always possible. It's all good in theory, but in the real world we often don't have enough power to fix all things.

• Ask the team to try to funnel all disturbances to the scrum master or product owner.

  Well, it's true, that the Product Owner and (especially) the Scrum Master should be a "shield" for the Development Team.

  The limitation of this approach is obvious. As I have been told before, the Scrum Master may not have enough authority to protect the Development Team well from unexpected on-demand tasks. On the other hand, requirements from business always is much more important for the Product Owner than the Scrum rules.

• Ask the team to designate one person as “goalkeeper”, all disturbances are routed to him, so that the rest of the team can focus. Could be the Scrum master or a rotating position.

  It's a "The Batman" answer, provided by @Aurora.

  Good solution with two limitations. 1) The Amount of unavoidable tasks should be not to big for "Batman". 2) The Developer Team should have more than 3 members, otherwise the сapacity (in percentage) will decrease greatly.

In any case, the presence of extraneous tasks in Sprint contradicts Scrum. It will be ScrumBut (not pure Scrum).

---

Also, you may look at the other methodologies:

• Extreme programming. According to this methodology, the customer may change tasks during iteration without any limitation (honestly, there is one limitation: in case the customer wants to add a new task to the current iteration, he should remove a task (or tasks) with the same volume).

  The trick is that the cost of changes have a fixed cost in Extreme programming. This methodology prescribes a lot of techniques about how to ensure this. One time I tried to implement this methodology, but it was too extreme for us :-)

• Kanban. This methodology has no iterations at all. When your WIP (Work In Progress) has a free space, you can take another task immediately. If you have no need in iterations, this methodology may be best the choice for you.

Answer 6

I like the Batman story. I'd just add that you should be strict about what constitutes a genuine emergency. It might be urgent for the user, but if it was forseeable they should have brought it up through the normal request process.

If you're lax with this they,ll soon cotton on and use it as a way to fast-track "nice to haves" through.

Real example. One Monday morning I got a call from an overseas office asking me to change their correspondence address. I told them to raise a ticket and asked when this was taking effect so I could deploy it into production at the right time. The answer: "Oh, now. We already moved".

Answer 7

This is short and sweet, but in my experience of the Scrum framework:

• Only the scrum team can decide to plan late work into the sprint.
• Only the Product Owner can agree for committed work to be dropped from the sprint.

The deliberate consequence of this is that the team can (will?) allow late work in if the product owner agrees to drop some work in exchange to make room.

All well and good when the work is all owned by the same PO, as he/she just has to decide what their priority is. In the event that work is owned by two different POs, then those POs need to decide between themselves what the priority is and the result of that discussion decides if an exchange goes ahead or not.

Finally, one of the principles of agile is to welcome late changes in requirements. That's not necessarily quite the situation you're describing, but I think accepting late changes in priority fits the spirit of agile just as well.

TLDR: yes people can come to you with late high priority work, but the business has to accept that in order for it to be taken on something else must be dropped. If your business is particularly prone to this then once POs have had their sprints disrupted or their late requirements rejected a few times they will by necessity get better at managing their backlog!

(Full disclosure: I'm a highly partisan and bloody minded coder. :-) )

Answer 8

Get out of the box, there are alternatives to Scrum. Maybe the nature of demand is not the best fit for the Scrum framework. Instead of beating your team to death with workarounds just try to come up with what works for you.

For example, in Kanban, you start where you are and improve by small increments. You may end up with a mature Kanban setup, with planning, batches and so on.