ScrumBut: Failure to Deliver


In this article, Michele Sliger discusses one of the more common "ScrumBut" practices that, while allowing teams to say "We suck less," isn't really in keeping with intended Scrum practices. This ScrumBut practice is the persistent failure of the team to complete the agreed-upon features in the iteration or sprint.

I'm frequently disturbed by the ease with which ScrumBut teams allow unfinished features to slide from one sprint into the next, creating a pattern of failure in meeting their sprint commitments—a pattern that the team considers acceptable. In these environments, it is normal to overhear quotes such as "Don't worry about it. We'll just finish it up in the next sprint," and "It's no big deal. We always have two or three stories that we don't finish." As Temple Grandin would say, "Bad is the new normal."

The failure to meet commitments should not be considered acceptable. If your Scrum team is doing this, please reconsider.

When I teach Scrum, I tell the new teams two things: 

  1. It is OK not to meet your sprint commitment.
  2. It is NOT OK not to meet your sprint commitment.

They are both true statements. The following F. Scott Fitzgerald quote explains the importance of the dichotomy: "The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function. One should, for example, be able to see that things are hopeless and yet be determined to make them otherwise."

It is OK to fail to meet your commitment when the team is new, or if unforeseen problems prevent getting to done, or if external issues like layoffs or natural disasters cause a slowdown. Every team—even a seasoned one—will miss meeting its sprint commitment on occasion.

But if the team has been working together for a while and knows how much it can complete on average in a sprint, then it is NOT OK to establish a pattern of not keeping your promise. A commitment is a promise. In Scrum, committing to a sprint is a promise to do the best you can to deliver what the team collectively said it would deliver in that sprint. If the Scrum team takes a lackadaisical attitude toward its sprint commitment, it means either that team members don't understand the meaning of the commitment or that the meaning has been altered to mean something else entirely. If it means something else, the team has moved away from the Scrum framework and values and into ScrumBut territory.

This ScrumBut practice is often indicative of the corporate culture. For some organizations, letting things slide and not keeping promises is simply in keeping with company values. Does that make the slippage OK? Absolutely not. It does speak to an organizational issue that should be addressed, which is one of the things that Scrum does so well: It makes problems highly visible very quickly, so that they can be resolved. If the corporate culture is accepting of this lackadaisical "We suck less" paradigm that tends to breed ScrumBut teams, then its leadership and vision should be questioned.

About the author

Michele Sliger's picture Michele Sliger

Michele Sliger has extensive experience in agile software development, having worked in both XP and Scrum teams before becoming a consultant. As a self-described "bridge builder," her passion lies in helping those in traditional software development environments cross the bridge to agility. Along with co-author Stacia Broderick, their book The Software Project Manager's Bridge to Agility focuses on the topic, helping PMI-trained project managers make the transition. Michele is a Certified Scrum Trainer (CST) and a certified Project Management Professional (PMP). If you have a question, or would like help with your agile adoption, Michele can be reached at

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!