A key agile principle is the value of getting planned work done each iteration. Yet many agile and scrum teams fall into the habit of letting unfinished work spill over every iteration. Spillover is when planned work such as a product backlog item or story is left unfinished at the end of an iteration and is carried over into the next iteration. Spillover occurs for one of three reasons. An overly ambitious sprint goal, too much unplanned work, or underestimating the effort required to complete the work. Occasional unfinished work is not a bad thing. In fact, it's normal and desirable to occasionally aim a little high in an iteration and come up short. Too many spillovers, however, can reduce predictability, diminish creativity, harm morale, and threaten project timelines. Before I get into why spillover happens and what to do about it, I want to make this point. A sprint goal is a commitment, not a guarantee. A commitment is a promise to try to achieve a goal. Sometimes we do need to make guarantees, such as when a client or customer needs some capability or fixed scope by a certain date. In these cases, to ensure they meet that guarantee, a team would likely cut back on other work and set a less ambitious sprint goal. In general, though, a team should not be forced into a guarantee. Instead, the team should be allowed to commit to something reasonable with leaders understanding the difference between a commitment and a guarantee. By the way, my name is Mike Conn, and I'm the author of three best-selling books on agile and scrum. I help teams succeed with agile. Missing on occasion is not a problem. Habitual spillover is different. Habitual spillover is when a team carries work forward on a routine basis. With habitual spillover, the end of an iteration becomes an arbitrary date and unfinished stories are just carried over into the next iteration as though it's no big deal. Frequently spilling over unfinished stories to the next iteration is a big deal for two main reasons. It decreases predictability and it harms morale. The main problem with habitual spillover is a lack of predictability and dependability. Every organization benefits from some degree of predictability. Predictability shouldn't be the primary goal, but it should be a goal. When your team is predictable, stakeholders will trust you and your work. There will be less second-guessing and micromanaging. So, this trust benefits everyone. But don't worry, you don't have to be perfect to be predictable. It's the same in sports. Basketball players strive to make every free throw, but a player who sinks the ball in the basket about 80% of the time is considered a high performer. that player can be depended on to make most of their free throws. Baseball players also strive to get a hit every time they're at bat. They're considered great, highly predictable hitters if they manage a hit about 35% of the time. Like those sports players, agile teams are expected to try to deliver everything they think they can every time. But if an agile team delivers their goal 60 to 80% of the time, they're highly predictable teams. A second related reason teams need to finish what they start most of the time has to do with the power of small wins. In a 2011 study, Amabolet and Kramer found that the frequency of small wins is an important factor in creativity and people's enjoyment of work. Successfully finishing the work of an iteration or achieving a sprint goal is a small win. Getting close to done is not a small win. So why do some teams routinely try to deliver more value than they can reasonably expect to deliver? The most common source of this bad habit is pressure. That pressure can originate from one of two places external or internal. External pressure can come from leadership, various stakeholders or from any outside source. An executive or stakeholder can exert pressure by establishing unrealistic expectations in terms of budget or scope. Sometimes this leadership pressure is well-intentioned. A leader gets excited about the opportunities presented by a product and wants more or they want to produce value faster because of the good it will do to the company or the product's users. More commonly, pressure comes from misguided leaders who think pressure is an appropriate way to motivate teams. In other cases, overcommitment happens because of internal pressure. Pressure team members put on themselves. Some teams allow their optimism and high expectations of themselves to create pressure to do more than is reasonable. Whether pressure to overcommit comes from outside or inside, it's neither a healthy environment for team members nor a good situation for the organization. Remember, we want to stop habitual spillover, not all spillover. Sometimes teams miss their goals when they aim high and fall a little short. Don't try to fix that kind of effort. Celebrate it. Other times, teams miss because they just hit a run of bad luck for a handful of iterations. Again, no need to intervene there. But when unfinished work spills over from iteration to iteration too frequently, here are three things you can do to help. One thing you can do right away to help stop habitual spillover is to share data on how prevalent spillover is. At the end of an iteration, note the percentage of product backlog items that are unfinished. If you can look back at a handful of additional iterations and do the same for those, bring this information to the next retrospective and ask team members why they think unfinished work has become a habit. Walk them through exercises designed to uncover the root cause of a problem, such as five W's. Then invite team members to discuss options and identify one thing they could try next iteration to alleviate that root cause. Encourage team members to hold themselves accountable for actually trying that one thing during the next iteration. Incomplete work in the form of unfinished product backlog items is often caused by an overabundance of optimism. A team plans an iteration as a bestcase scenario and pulls more work from their product backlog than they can achieve. If that sounds familiar, in your next iteration planning meeting, try asking questions like these. What has to go right to achieve this goal? And what could go wrong that could cause us to miss our goal? That might be unplanned work, a backlog item becoming bigger than expected, unforeseen scenarios such as critical bugs, integration issues, and so on. These questions can help uncover any risky assumptions about the work the team is about to bring into the iteration. Think of it as a premortem for the iteration. If you're a scrum master and nothing you've tried can get your team to break their spillover habit in the next sprint planning meeting, encourage your team to truly undercommit in relation to their team capacity. I'm not talking about cutting the sprint goal by some small amount like 10 or 20%. You want to reduce the amount of work they commit to so dramatically that they are guaranteed to finally achieve everything they say they will. The team will probably push back on this. They're used to filling up their sprint and will be optimistic that they can get more done than the items they've chosen, but their history shows they won't. Scrum masters should hold firm, reminding team members that if they run out of work, they can always bring more in. Scrum masters will likely need to have a talk with the product owner prior to sprint planning so they too can be prepared to hear that the team is bringing less work into the sprint, but with the goal of finishing everything for a change. The goal in undercommitting is to let everyone on the team, including the product owner, feel what it's like to add work rather than always spilling work forward into the next iteration. After they do, they'll likely want to feel that way again. Once the team has felt the joy of no spillover, the scrum master should encourage team members to plan a bit more work into the next iterations until they get close to having to roll over incomplete stories again. Habitual spillover can be a hard habit to break. Agile teams need to perform their best while also allowing the organization to create reliable plans. To do that, you want a team that knows its capacity and at the same time isn't afraid to try hard things. You also need a product owner and stakeholders who understand that an ambitious team will not accomplish its goal every iteration and that understands the difference between a commitment and a guarantee. Old habits die hard. Sometimes you have to take drastic action to realize lasting results.