Artificial decomposition in Scrum

Question

Scrum Guide says:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.

But not every task can be broken down into sub-tasks that can be completed during one Sprint. More over, it just doesn't make sense to decompose every large task - some taks are just very cohesive and trying to decompose them just creates artificial impediments for developers. Insisting on such a decomposition would be counterproductive and artificial.

It looks like Scrum doesn't address this issue in any way?

Examples include:

• upgrading a software library to a higher version (requires of lot of small code changes all over the code base, fixing issues, debugging, etc)
• introducing an architectiral change
• refactoring
• investigating a bug
• configuring some software
• etc

Answer 1

It looks like Scrum doesn't address this issue in any way?

No, it doesn't.

Scrum is a guide. Although it prescribes stuff, it doesn't prescribe a lot of stuff. This is one of the things that are left at the discretion of the implementer. For ex, it used to provide a sample for 3 questions to ask during the daily, but those were dropped eventually (probably because many took those questions as prescribed and focused only on those instead of thinking for themselves).

In that paragraph the guide says that things should be decomposed so that the team understands them and can do them in a sprint. The smaller the better, because that refinement increases understanding, minimizes unknowns and risks, and avoids making assumptions about things. How small or how large isn't mentioned, just that they can fit in a sprint (although a common advice you will hear, and rule of thumb, is about 1-2 days per PBI).

Of course, life doesn't play by Scrum rules all of the time. When you turn something on all its sides and you still can't fit it into a sprint and deliver it in an increment, you have to use common sense for how to handle it. Sometimes it takes more that a Sprint to do something - s#it happens - so you address it in a different manner (whatever the team decides with the PO). But the idea is to have this as the exception, not the rule.

Answer 2

I know there is an accepted answer, but I find it to have a bit of a trap in it, so I want to provide this answer for another view.

I've been practicing Scrum for about 15 years and I have yet to encounter a task that could not be usefully broken down to less than a sprint. This has been in industries ranging from construction to marketing to research on quantum computers. However, I have encountered tasks that I was unable to break down at that time. In these cases, I think it is important to give it the old college try, but don't get hung up on it. Acknowledge you don't know how, then get to work. However, learning is a critical part of Scrum. When you encounter these and finish those tasks, look back and find ways in hindsight that you could have done pieces. This is much easier and this is how I got to the point that I could tell you how I'd break down any task I've ever done to smaller than a sprint and have it deliver something useful.

Edit: This is to fill in the idea of "useful". I do mean that it meaningfully progresses the product without additional work. This may be clearing risk, answering market or business or technical questions, user functionality, and addressing other user needs like performance or security. This would not include planning, reading up on technology, or other partial tasks.

Answer 3

First of all backlog items should not generally be "tasks" at all. Wherever possible backlog items should be deliverables, features or other outcomes. Do you have an example of a backlog item that cannot be split? Most big deliverables can be split.

Consider a typical sprint consisting of 10 working days (2 weeks is probably the most common sprint duration) and a team of 8 people (Scrum teams are usually between 3 and about 10 people). That means a backlog item is something that should be capable of being done with less than about 80 days of effort. 80 days effort is quite a big cost and a lot of work to put at risk in one go. If your backlog items are really that big then it is almost certainly worth the effort of breaking them down because doing so reduces delivery risk and ultimately improves productivity.

If you do a search for "story splitting" you will find lots of examples of interesting ways to split up backlog items.

Answer 4

Further complicating the real-life situation is that there can be complex dependencies among the identified tasks, reflecting the architecture of the underlying system. Scrum is, and can only be, a guide. Take it for the many very-good ideas that it contains, but don't worship it.