Scrum: how to handle backlog-items that are longer than one sprint

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

I agree with 4 weeks being a long sprint these days. You want to decrease the feedback loop and getting better at turning small units of work around in shorter iterations. That way there is less to go wrong, less that will change and less complexity to manage in one go.

Splitting stories is often a trouble area for people but you get better with it the more you do. Work closely with the PO to work out if you can deliver it in stages and still deliver value in the sprint.

Here is a great poster that helps with splitting stories, its from a website called agileforall.com and you can find the poster here, its really useful to have this up as you refine backlog items:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

It is also good to have your definition of done available when you refine and plan so that you can keep that in mind when committing to complete something in one short sprint.