Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm starting with SCRUM and I have a problem understanding one thing. How does SCRUM handle backlog items that take longer than one sprint?

share|improve this question
did you try to split them into meaningful backlog items ? – David Aug 24 '11 at 7:57
at the moment, it is more a problem that I think I will encounter in the future - and I'd like to handle it correctly. – Tobias Langner Aug 24 '11 at 8:07
up vote 22 down vote accepted

Such items are either called Epic and must be divided into smaller user stories which are shorter then a single sprint and because of that can be planned, or Theme which will be divided into Epics and those into common stories. Epics and Themes share the main characteristic - high level of uncertainty = they cannot be properly estimated (estimate is usually very high and because of that they do not fit into a single sprint).

So it is good to start with such stories but you cannot plan them until the product owner breaks them into smaller specific stories. These stories are used only to make note of some bigger requested features (Epic) or whole feature sets (Theme). Breaking these stories will make the feature specific.

It also follows Iceberg structure of the product backlog.

share|improve this answer

You don't have such items. If you have, then the backlog item isn't specific enough and hasn't been properly broken down into smaller items. Some people call them not backlog, but fatlog items and in Scrum they are considered a anti-pattern.

The cake analogy user story: As a cake-eater, I want to eat cake in the afternoon. I can't eat a whole cake in one afternoon, so it needs to be sliced to fit the amount I can eat.

share|improve this answer

When Scrum was first "invented", the default sprint was normally 4 weeks.

According to what I have been told, the reason for this very long sprint size was simply because people at that time had a very hard time imagining that you could possibly accomplish anything in shorter sprints.

As teams got more confident with scrum, they learned how to better divide backlog items into smaller items of more manageable size, and the development teams got better at not overdoing the up-front design, but just doing enough.

Today, I believe most teams would consider 4 weeks to be very long sprint duration. I am of the impression that 2 weeks is quite normal. XP teams do only 1 week iterations, and they finish complete user stories in each iteration.

So you need to be better at dividing the backlog items into smaller items, that each give a small increment in business value to the final product. It is possible, that has been proven. (though I will not rule out that there could be very specialized domains where it would be difficult)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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