A successful Scrum team is responsible for not just the quality of their work, but also the quality and professionalism in how they DO their work. In this article, we will discuss how a team bares responsibility for the Sprint and what they should do if they discover they can’t get everything done that they committed.

If you want to build a successful Scrum team that routinely delivers what they say they will, there are a number of practices that will be key to your success. We talk about many of those on this website, including working on small backlog items, limiting your work in process, having team ground rules, DONEness definitions, and how to do effective Sprint Planning. If you can get your team engaged in all these practices, you will be well on your way to creating a high performing team. Another practice that will help your team to become more and more predictable may seem simple and quite obvious, but is often overlooked by teams until it’s too late — keep checking against your sprint goal.

Like I said, it sounds obvious, and traditional project management methods recommend regular status meetings to verify the state of the project and head off risks and other potential wastes. Your Scrum teams can benefit from this same practice: by checking every day whether or not the team is on track to complete their goal for the Sprint, your team can take pre-emptive steps to correct any potential roadblocks to delivering what they committed.

For example, let’s assume that, during a daily Scrum, the team has determined that one of the product backlog items that is in progress is running seriously behind. Some teams just leave it at that; when the daily Scrum is over, they all go back to work! What’s the point of that? If a daily Scrum unearths the reality that the team might not achieve the goal for the Sprint, shouldn’t they do something about it?

Well, yes, of course!

So, let’s suppose that the team in question, having learned during the daily Scrum that they might not achieve the goal for the Sprint, finishes the daily Scrum and then begins a discussion as to why. Why aren’t we going to achieve the goal for the Sprint? What changed? We, the team, committed the work during the Sprint. Is the situation we’re in something out of our control? In the Scrum Patterns website, Jeff Sutherland (the creator of Scrum) suggests the following steps when the team determines they might have a problem:

1. Change the way work is done. Do something different.
2. Get help, usually by offloading backlog to someone else.
3. Reduce scope.
4. Abort the Sprint and replan.
5. Inform management how release dates will be affected.

“Changing the way work is done” leaves a lot to the imagination. Are the right people working on the right tasks together? Often, when we try to do some cross-training, we lose productivity for learning time. Maybe we shouldn’t do that this Sprint. Are we using a tool that is taking too long (often trying to “do it right” means taking a lot of time to do something when there really isn’t a lot of value in the extra effort). Was there a more expedient solution (maybe not the “best” one, but one that would work and cost a tenth of the time)?

“Get help, usually by offloading backlog to someone else” means just what it says. If your team can’t everything done, is there a way to move work to another team or is there a way to get someone to temporarily help the team. I’ve seen both done. Working on a large project in Germany, there were teams that found themselves behind and the ScrumMasters would work together to find a way to redistribute the backlog items to allow everyone to get done. When I worked for a large multi-national, my mentor suggested that all Scrum teams should always strive to be right on the edge of being able to finish everything committed. If a team got behind, a team that was ahead would automatically come to their rescue and balance the workload. My mentor even suggested using traffic lights for every team room. Teams that were ahead would be “green,” teams behind were “red,” and teams on the edge were “yellow.” Green teams would come to the aid of the red teams and attempt to get everyone to yellow.

“Reduce scope” is pretty clear. This is what the Scrum framework suggests out of the box. Jettison backlog items from the Sprint Backlog back to the Product Backlog. And don’t wait until the end of the Sprint to do it. Do it now! Keeping the workload achievable is what helps teams learn to do better.

“Abort the Sprint and replan” if there’s just no way to fix the Sprint, it’s pretty fouled up. Remember “fail fast?” Rather than waste more time fixing a sinking boat, jump off and get yourself a new boat. Terminate the Sprint and plan a new one.

“Inform management how release dates will be affected” means to ensure that management is aware of the impact of any changes that you may have made that might affect the release dates (if there is any affect). Always keep management informed of what’s going on and why. Keeping management in the dark never works out well in the end.

Remember, bottom line, the TEAM IS RESPONSIBLE for the quality of the Sprint. Not the ScrumMaster by him or herself. Not the Product Owner. Not management. If the Sprint is in trouble, it is up to the team to fix it. Always keep your eyes on the goal!