Why is it important to only have PBIs completable in a single Sprint?

Question

In Scrum it is emphasized that the Sprint Goal is achieved and that the developers determine which work can be completed in the Sprint. I often get the following question:

Why can't we start a story that we think might take two sprints to finish? Isn't it better to at least have the Story started, even if we can't finish it?

I am having difficulty finding reasons not to do this. What is the reason for only having product backlog items that can be completed by the end of the Sprint put into the Sprint Backlog?

Answer 1

The point of the Sprint is not to finish work in the Sprint but to accomplish something within the Sprint. There is a difference between the team having an output and an outcome.

Obviously, in order to accomplish some outcome you have to finish the work selected for that outcome. If you don't finish the work in a sprint then it means you haven't reached your outcome within that sprint. So this is one reason you want to finish work, because otherwise your outcomes span multiple Sprints, and that kind of invalidates the reason for having a Sprint in the first place.

The Sprint is a cadence or a heartbeat for accomplishing things. You then hold a Review meeting where you collect feedback about the Increment (or Increments) you have built that Sprint. Everyone gains a shared understanding of what was done and you can then plan things out about the Product going forward. Finishing work sooner rather than later also minimizes unknowns and risks, and avoids making assumptions about stuff because you have something to show and ask for feedback, sooner rather than later. Kanban for example says to minimize work in progress because that has some advantages over people working on stuff for longer periods of time.

So the point of the Sprint is not to finish work or at least start some work even if you do not finish it. It is to accomplish something, show it, get feedback, then replan as needed based on the input you get. Making an effort to split something in smaller parts and work on those is always better than to drag things along with you from Sprint to Sprint (see again the details in the Kanban link). Sometimes there are exceptions (each team's reality is different) but those exceptions open up the door of doing work with no reason to finish it in this Sprint, which again, invalidates the reason for why the Sprint is useful.

Answer 2

I want to supply a bit of a purist answer not because it is necessarily more "correct" than some of the others, but to give a different perspective. In many modern implementations of Scrum, the next 5 sprints are assumed. We plan very large projects into a set of sprints. This does deliver some value, but it misses part of the core point of Scrum: short decision cycles. When we have already decided that we will spend the next quarter working on a set of features, sprints become more of a pace-setting exercise than anything else. It becomes like an auto race where each lap we look at our position and make small adjustments, but we know we're in for the full race.

A missing piece is that the team should be able to pivot (or end) at the completion of every sprint. Each sprint delivers a potentially shippable increment and it is within the power of the PO and stakeholders to say "Great, that's it, thanks, we're done now." When you introduce this constraint, the problem with leaving PBI's unfinished becomes obvious.

Answer 3

The idea is to break larger PBIs into items small enough to accomplish within a sprint. There are multiple advantages of doing that. From the customer's point of view it means they get something faster and they have evidence of the team's ability to deliver value on a regular basis, regardless of the size and complexity of the work. Fixed iterations also help to manage delivery risk when faced with changing priorities. If a PBI delivers no value in a given sprint then any work done on it is at risk because if priorities change in the next sprint then maybe none of that work will ever be of use.

Teams new to Scrum often struggle with the idea of breaking PBIs into items small enough for a single sprint. There are lots of examples online of how to do story splitting. It does usually get easier with practice.

There is nothing wrong with picking up new backlog items during the sprint if the team finds they have spare time available. Some teams like to leave a little bit of capacity in the sprint to allow for that.

Answer 4

TL;DR

You must strive to complete selected Product Backlog items (PBIs) within a single Sprint if you're following formal Scrum. You should strive to complete them within a single Sprint if you want to achieve the benefits of an empirical control model and business agility, both of which require a very tight inspect-and-adapt loop.

Why Sprint Boundaries Matter in Scrum

There are three basic reasons that PBIs accepted into Sprint Planning must be completable within a single Sprint. First and foremost, this is required by the official Scrum Guide's definition of the Increment in order to avoid incomplete progress towards defined Product and Sprint Goals (see also the Definition of Done):

Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

A partially-completed PBI can't be "thoroughly verified" and is unlikely to be usable until some future Sprint. This is closely related to the INVEST mnemonic, which requires that stories be small, testable, and valuable. A PBI that spans Sprints isn’t small, and its testability can’t be demonstrated or its value realized until it’s finally completed.

Secondly, a PBI that spans Sprints violates the principles that underlie the Sprint Goal. If the story is not essential to the Sprint Goal, then it violates the principle of central coherence.

The Sprint Goal is the single objective for the Sprint...The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Thirdly, if it is central, then the Sprint Goal can't be achieved by the end of the Sprint because the Definition of Done can't usually be met through partially-completed work essential to achieving the Sprint Goal. In effective agile frameworks, work is either "done" or "not done." Anything left undone by the end of a Sprint must be put back onto the Product Backlog to be re-prioritized, re-estimated, and re-planned in a future Sprint. The Scrum Guide states:

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Since the prioritization and contents of the Product Backlog can change at any time, but especially at Sprint boundaries, a given PBI may never come back into scope. As a result, deliberately planning partial work leads to wasted effort and a waste of scarce Scrum Team and project resources. In turn, this often leads to the sunk cost fallacy, which Scrum theory very deliberately sets out to avoid as part of its dedication to the empirical control model.

Answer 5

Sprint-spanning stories are problematic for several reasons. First of all, it is obviously a good goal to plan your sprint such that you can finish it by the end - else there would be little reason to have the sprint structure at all, and you could just employ a flowing Kanban-style process. That said, I have worked in projects which had a more relaxed stance on this, and it was OK - if and when all people involved, including product owner and stakeholders, were aware with it, and if it was acceptable to all of them. The projects felt more like Kanban projects, but used all of the SCRUM artifacts (dailies, planning, review etc. sessions).

A second reason to avoid long-running stories is if your single project is related to other agile projects, for example in the context of a SaFE or LESS-based larger environment. In this case, it is quite critical that the individual projects have synchronization points, especially if there are technical interfaces between the applications.

Coming back to the project itself: in one of my projects we don't even plan stories which would load one person fully for the sprint duration, but we limit ourself to stories which would load one dev for half of the sprint (per story). The reasoning here is that if we have a story so large often is an indication that it is not designed correctly (unclear requirements, too large interdependencies etc.). By forcing ourselves to cut it smaller, we really force ourself to be clear on the reqs, and also make it possible to work in parallel, if at all applicable.

Also, if and when an unplanned showstopper occurs for a very long-running story, you might not have another good story to work on in the sprint (because you planned for one dev-capacity to be completely blocked by that one story). This also reduces your flexibility. If you only have smaller (independent) stories, it makes it much easier to switch work to another one, for the affected developer.

Having smaller stories makes it more likely for another dev to take over, if one of your colleagues becomes ill or otherwise unavailable.

Finally, being able to finish a story is always a great feeling for a developer. Having more stories means having more of these events - always a good thing! This really creates a gamification situation where people (aside from producing useful products) also enjoy ticking of lists. For some, this is definitely a motivator (compare with all the personal time management systems like GTD, bullet point lists and such).

Of course you always will have larger feature sets which you simply cannot finish in one sprint. There are the "Epic" or even "Saga" mechanisms for this, where you have a bracket to track long-running implementations.

TLDR: So there you have it. There are plenty of good theoretical and practical reasons for having smaller stories, and I know of none to have larger ones.