How to deal with recurring tasks in a sprint?

Question

We are working on a software product which by now requires about 40% of our capacity maintenance work like e.g. manually checking data per day. What would be the recommended way on dealing with those tasks within a Scrum framework?

At the moment I do see 3 solutions:

Move them out of the sprint/backlog as Scrum Backlog Items (SBIs) should be one time problems and reduce capacity of the team accordingly. Which would result in intransparency of tasks that need to be done (in order to keep our product alive)

Treat them as regular SBIs and keep them in the sprints. One per day, resulting in a cluttered backlog and during sprint change the PBIs need to be done as well but are not reflected in the stats/planing. Try to automate those tasks and reduce the amount in the future.

Create one SBI with a checklist and one line/checkbox per day to be checked. This would result in being permanently in progress and belonging story points will reduce the burn down chart only at the very end of the sprint.

What do you think and is there a solution you know from experience that would work?

Answer 1

A common theme in agile methods is about communication, visibility, and transparency in the work that is being done and what the status of that work is, ensuring that the right stakeholders have access to this information.

Without knowing all of the details about this work, it seems like the Product Backlog is not the right place for these. The Scrum Guide defines the Product Backlog as "an ordered list of everything that is known to be needed in the product." Unless this work represents something that the product needs, I would simply ensure that the work is placed into the Sprint Backlog during Sprint Planning. This can help the team to ensure that they consider it when crafting the Sprint Goal and selecting Product Backlog Items for the Sprint. I would put each task as a separate item in the Sprint Backlog and even estimate them like you would other work in order to be able to show the impact of this necessary work on the ability to deliver other work for the product.

Long-term, though, it seems like regular work that involves 40% of the capacity is something that should be addressed. I'd question if a development team represents the people who should be doing this work. Alternatively, I'd want to know if there are ways to automate the process to some degree so that way the burden can be reduced, especially if it's an ongoing process.

Answer 2

How to deal with recurring tasks in a sprint?

It really depends on what type of work is performed in those recurring tasks.

If the work is about fixing bugs for the application, adding new functionality, any kind of product enhancements, or work that creates a product increment and can be a goal for sprints, then it belongs in your sprint and in your backlog and you handle it just like any other story.

If the work touches more on the side of user support (manually checking data, verifying various information to respond to user questions, offer support over phone/chat/email, etc) then this work should probably best be pulled out from your sprints and from your backlog. I've worked with teams that functioned in similar environments and they found a simple and effective solution:

• they pulled one person out of the sprint and had them working on "operations";
• a separate Kanban board and backlog was created for this activity;
• to keep it fair for everyone, it was a different developer each sprint, by rotation;
• this developer would not participate in developing work in the sprint, but could attend sprint planning, daily meetings, and retrospectives, to keep in touch with what was happening in the sprint while they were handling "operations";
• any work they did while out of the sprint was recorded in the Kanban board. If it was strictly support, it stayed in the Kanban board and the Kanban backlog. If it proved to be something that enhanced the product, they would create backlog items in the Scrum backlog and let the others handle it (i.e. if it was support, they dealt with the work. If it was product development they threw the work over the fence to the Scrum team which handled it like any other item in their pipeline).

This approach kept things moving on both pipelines (support and development) and protected the Scrum team from work that had little to do to with enhancements of the product. The person doing support was sometimes not fully utilized, but that was not the point.

Finally, if the repetitive work can be automated, then do so and have a machine do the work.