14

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
7
  • 6
    Do you have an example? Do you mean breaking down PBI's so that they fit in a single Sprint, or breaking down a larger PBI in a single Sprint? – Niels van Reijmersdal Mar 30 at 11:27
  • 9
    Examples please. The whole tradition of problem solving by decomposing problems into manageable subproblems is as old as humanity. Whether you build a house, run a marathon, send a rocket to the moon, the problem gets decomposed to the level of setting individual stones, making individual steps, turning individual screws etc. Which actual problem can't be decomposed into parts that can be done in a limited time by a limited team? – Hans-Martin Mosner Mar 30 at 11:41
  • 1
    When you say "this can't be broken down in a useful way", what you're really saying is "I can't see a way to break this down in a useful way". This might mean there doesn't exist a way to break it down, but it's far from a proof that there exists no way to break it down. – NotThatGuy Mar 31 at 9:45
  • 1
    Not knowing how to split large tasks into smaller chunks is a typical junior dev issue for me. Everyone is like this when they start. But as you gain experience, chunking work into pieces becomes second nature. – Davor Mar 31 at 10:37
  • 2
    A JSON parser can be developed one type at a time. A compiler can still be broken down into parts and shipped with very limted features. This doesn't mean they'll be useful, but they'll still be shippable. – Erik Apr 1 at 8:52
15

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.

4
  • 2
    I feel like this is a "good" answer, but there's also a trap built into it. I think it is very easy for someone to read this answer as "do it when it's convenient" and that would be unfortunate. – Daniel Mar 30 at 14:17
  • 3
    @Daniel: to be honest, if people do this just because it's convenient, I doubt that they will look for approval first, stumble on my answer and say "Yup! This guy says we can. Let's do it all the time" :) I've emphasized a few things in my answer as well as the ending sentence just to try to be more clear that this would be an exception. I don't really want to rephrase it to say that there should never be an exception, because that's not always reality for everyone. – Bogdan Mar 30 at 15:23
  • Ha! That is a very good point. – Daniel Mar 30 at 17:04
  • 4
    An addendum might be to flip the 2nd paragraph around. If you think it's a 'good' idea to support tasks longer than a sprint, recognize that Scrum will not provide you any constraints on that developer's efforts. if you're okay with a developer going off for 3+ months and coming back with a solution, great! You probably have another system of feedback ensuring that upper management is confident their work is on schedule, which is supplementing Scrum. Is that system agile enough for your business needs? – Cort Ammon Mar 30 at 22:35
11

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.

1
  • 1
    And by "useful" I'm guessing you don't mean useful to the business/end users? Because I frequently see tasks which can't be finished within a week. As a matter of fact many of them take several weeks or even months of development before they become useful. I can still break them down of course if needed, but it won't make the individual pieces useful to the end user or stakeholders. So would be great if you could define "useful" in your answer. – Stanislav Bashkyrtsev Mar 31 at 0:09
6

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.

1
  • I edited the question and added some examples of tasks that may not make sense to split. Also it often doesn't make sense to work on one task together - for example I don't suppose that a bug should be investigated by the whole team, one developer is often completelly enough. – Daniel Apr 6 at 12:59
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.