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.