How should large non-reducable tasks be handled in Scrum?

Question

How are tasks that do not fit in a Sprint handled in Scrum?

I see the benefit in delivering incremental value each Sprint, but I don't see how all tasks can be reduced to take no longer than a week or two (and I suppose a single story in a Sprint is an antipattern).

Consider the following tasks:

• Fixing a critical bug that is hard to pin down and resolve
• Following up with an external partner during a security or safety review
• Replacing a commercial off-the-shelf component with a self-built component after the self-built component reaches parity
• Implementing a feature that may seem as simple as a single button press from the user's perspective, though a bare minimum implementation that carries out the task intended by the user is very complex

Each of these tasks may take the majority of the time for one or more team members for many weeks. Any reasonable definition of done, that can be achieved in a week, will not provide any incremental value.

In chapter 8 of "Scrum: The Art of Doing Twice the Work in Half the Time", Jeff Sutherland writes:

It can be difficult to imagine incremental releases [...] that don't seem [...] to have any value until they're complete

[...]

try to think ... What is the absolute least I can build and still deliver value to a customer?

I hold the opinion that some pieces of the systems I build, while providing tremendous value, cannot be delivered in small increments.

How does these kinds of tasks fit into Scrum?

(While I have used the term task, I guess 'story' would be more on-brand for Scrum, though in my view the concept of stories is an aid to communicating tasks. Even if you would like to argue that my examples are epics, or something else, I claim that they do not provide small incremental value to the project)

Edit in response to Thomas Owens

I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint.

This is the answer to the question I should have asked. The way I understand Scrum, every task has to be small enough to be included in a Sprint, and always deliver incremental value.

In my experience, this is not possible. It also seems like a very strong assertion. I mainly work on embedded systems, and it is my experience that these kinds of long-running tasks occur more on the embedded side of IoT systems rather than the in the cloud or on the frontend.

I will consider formulating a more specific question for a given case, though it is hard for me to make sure I do not reveal privileged information. This seems to be a more specific example where I would suppose that delivering every piece of value in small increments would be hard.

Answer 1

I'm not convinced that what you describe fits the notion of "large, non-reducible tasks". So far, I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint.

Fixing a critical bug that is hard to pin down and resolve

The steps here are pretty straightforward: Get reproduction steps. Reproduce in a development/test environment. Write failing test cases. Fix. Deploy and verify fix in a test environment. Deploy to production.

I do remember one critical bug that was hard to resolve because of a lack of logging. The reproduction steps were there, but under some conditions, they didn't reproduce the defect. So we deployed additional observability to the production environment through logging. Having application performance monitoring and logging going to a central service, we were able to wait until it failed again and then could solve it for real.

Just because a bug is critical doesn't mean that you can solve it immediately. Taking the next possible step toward a resolution should probably be the most important thing that you do, but sometimes you need to set up for information gathering, wait for the information, and then proceed. Define the work to improve observability into the system, deliver that, and then proceed with the actual bug fixing when you can.

Following up with an external partner during a security or safety review

I don't see how this is large. You are sending an email or making a phone call. There may be some iteration based on results. Maybe the security or safety review found issues. Track each step. It's important to realize that this type of work has external dependencies and they may not be on the same cadence as the team doing the work. But you can decompose the work into smaller pieces.

Replacing a commercial off-the-shelf component with a self-built component after the self-built component reaches parity

It may not be possible or desirable to deliver this in pieces, but the work can be designed, developed, integrated, and demonstrated in increments. This is a good opportunity for risk-based prioritization of the work. Find the replacement that brings the highest amount of risk or uncertainty, do that first, and build confidence that your replacement will work.

Some people may argue that this isn't "real Scrum", but there are several aspects of Scrum that don't always align with real-world situations of contexts.

Implementing a feature that may seem as simple as a single button press from the user's perspective, though a bare minimum implementation that carries out the task intended by the user is very complex

I'd have to understand more about the context, but I've often been able to slice these into thin end-to-end pieces. This is a good opportunity for feature flags, though. Some thin slices may not enable full robustness or error handling. Being able to implement the functionality in thin-slices, turn on the functionality in demo and test environments to get feedback while making sure it's integrated with the rest of the system, and then enabling the feature when it's sufficiently robust is a good strategy.