How can we track Business as Usual (BAU) work?

Question

My team, which consists of network architects and developers has been running Scrum for the past couple of months and the biggest issue we have is how we're supposed to record BAU work.

We consider BAU work to be things that are repeatable (i.e. provisioning a new user account) that we have to do from time to time that do not relate to our project at all. We can't give these tasks to people outside of the project because we're a small team and have day to day functions outside of the project.

We use a JIRA project to run our Sprints and have considered using Trello or another JIRA project to keep track of our BAU work. We haven't implemented any of these yet since we're still mulling over potential options and haven't identified success criteria yet.

Answer 1

I have seen three variants depending on the nature of interrupting tasks:

---

1) Capacity

If the work is very evenly distributed, just subtract it from the capacity beforehand.

Example:

Every developer in the team has a one-hour one-on-one meeting with heir line manager during each sprint. Every developer has to fill out their timesheets. There is a scheduled fire alarm drill for all personal in the building this sprint.

---

2) As a story

If the work is predictable, make a story of it, estimate it and put it into the sprint.

Example:

After the rollout of the new library, the sister team will need help implementing it in their own product. Questions or difficulties are not known yet, but will arise as soon as they start working.

---

3) Batman

If random requests will pop up in random frequencies and random quality, you need someone to answer the red bat-phone when it rings.

Decide on a single person per sprint who will handle all those requests. Their work will probably be interrupted constantly. They might not produce anything towards the goal of this sprint. But at least the interruptions got contained and the rest of the team could focus on the sprint at hand. In addition, it's easier to measure how much time was lost to those tasks, compared to giving them to different people and having to come up with a number afterwards.

Example:

any kind of support work.

Answer 2

My initial thought is that Scrum is not appropriate for this situation, and something like Kanban is more appropriate. In cases where much of the work is BAU work that appears suddenly, you don't have the advantages of being able to plan a Sprint cadence and regularly deliver a set of value-adding work at the end. Low amounts of unplanned BAU work means that you end up pulling more work anyway, while high amounts of unplanned and urgent BAU work means that you can't finish your plan. A continuous flow of delivery of value based on urgency and priority with just-in-time planning of work seems to be a better fit. You can choose to have activities, such as review of delivered work and retrospectives to improve the process, on a regular cadence or done just-in-time.

One possible area where you may be able to apply Scrum is if your service level expectations for BAU work is greater than your Sprint cadence. That is - regardless of when the BAU work comes in, the majority of it does not need to preempt planned Sprint work. There still may need to be some cases that are critical, but consider software development teams that are maintaining a system in production - these production fires that preempt planned work should be the exception and not the norm.

Regardless of the solution, I would advocate for using a single tool. Visibility is important, and if the BAU work is impacting your project work, it would be more difficult to make that visible if the work was being tracked in two separate tools.