Posted on November 25, 2015
by Doug Klugh

As Scrum becomes ever-so-popular among software development teams, some people may actually wonder why.  Certainly increased productivity and improved quality are on the list, but predictability is a huge benefit that is often over-looked.  Whether your product development is driven by schedule, scope, or budget, being able to accurately and consistently predict when a set of features will be done is often critical to a successful product launch.  And considering how often Waterfall projects miss their mark, it should be no surprise why Scrum has been so successful (when done correctly).

At this point, many of you may be saying "but our Scrum projects aren't any more predictable than Waterfall projects."  And sadly enough, my experience has shown that is this is the case more times than not.  Why?  Because most Scrum teams do not meet their sprint commitments.  In fact, most teams don't treat them as commitments at all.  A lot of teams treat their sprint backlog as a wish list.  And that is where predictability fails.

When done correctly, Scrum provides a very simple, yet very effective way to build predictability into product planning.  The key to this working is the team meeting their sprint commitments.  If they are carrying incomplete cards from one sprint to another, you lose predictability.  Over time, the team will naturally get better at estimating work, but if they don't deliver on their commitments, you won't have a consistent (predictable) velocity and you will lose reliability in your plan.

At all the companies and all the teams I have coached, I always stress the importance of fulfilling their sprint commitment.  During every sprint planning meeting, after the team has committed to a sprint backlog, I always go around the room, in a round-robin fashion, and ask each individual team member if they are committed to meeting the sprint commitment; to completely finish (according to the team's definition of "done") all (sprint) backlog items within the sprint.  Scrum teams must treat this as a commitment.  If issues arise during the sprint (and they always do), we need to do whatever it takes to resolve those issues to meet our commitment.  And if that requires working 16 hour days, then that is what we do.  After all, it is a commitment.  If the team misses their commitment on more than rare occasions, they will lose trust with the Product Owner and other stakeholders.  And as we all know, once you lose the trust of your stakeholders (or worse, your customers), it is very hard to get back.
backlog commitment schedule scope Scrum sprint

Doug Klugh

Doug is an experienced software development leader, engineer, and craftsman having delivered consumer and enterprise firmware/software solutions servicing more than one billion users through 20+ years of leadership.

Similar Articles

subject Article

The Absence of Commitment

Back in 2011, Ken Schwaber and Jeff Sutherland, the established authorities on Scrum standards, replaced the term commitment with forecast within the official Scrum Guide.  While this may seem like a minor, irrelevant change, the implications are indeed significant.

Read More
subject Article

A Dozen Ways to Fail at Scrum

Scrum provides a process framework to help realize the benefits of Agile principles.  The value of Scrum has been demonstrated many times, on numerous projects, throughout various industries.  It is a fairly simple and straightforward set of practices and guidelines that will (usually) result in greater adaptability to change, improved productivity, high quality products, and happier customers.

Read More
subject Article

Agile Is More Than Process

There is more to Agile than estimating stories, collaborating with customers, and showing working software.  Agile is also about technical excellence.  And this is where many Agile teams drop the ball.  All too often, teams focus too much on process and not enough on technical practices.  If the effort, complexity, and risk is too great for your team to extend and maintain their software, they will struggle to deliver functionality to their customers at the end of each iteration.  They will struggle to deliver working software as promised.

Read More