Get certified - Transform your world of work today

Close

The Sprint Backlog: My Experience with a Small Change Toward Commitment

14 February 2017


I am a firm believer in kaizen, the philosophy that states simply, "change is good" and promotes generating continuous improvement through incremental change. As such, I want to share a recent small change we implemented with our Scrum Teams, which showed a notable and positive impact. This change is so slight that you might call it a change in perspective, as opposed to a change in process. However, the improvements that this small change has set off were notably larger.

The change relates to the sprint backlog and how it is perceived. The Scrum Guide describes the sprint backlog as a forecast, and this is, of course, true. To quote the Scrum Guide: "The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next increment and the work needed to deliver that functionality into a 'Done' increment." Beautifully said.

I proposed one change to my teams that was specific to this phrase. Again, it is merely a slight change in perspective, which actually aligns with Scrum Guide versions of yore. It goes like this: "The sprint backlog is a commitment by the Scrum Team about what functionality will be in the next increment and the work needed to deliver that functionality into a 'Done' increment." Just one word, forecast, was swapped out for a different word commitment.

"What’s the difference?" you might ask. "The word commitment doesn’t change the reality of the situation. We, the development team, can get done only what we can get done. Stop pressuring us!" To which I would respond, "You’re right!"

You might further say, "Anyone who’s worked in software knows that things come up — bugs are discovered, requirements change, tests we thought were written weren’t. You name it. Any number of things can happen, which even the most diligent sprint planning can miss. It is moving away from Waterfall-like deadline commitments that is so important in Agile software development."

"Right you are!" I would again reply.

Good grief! When a sales team or executive staff artificially commits a software development team to a scope and deadline, it is almost certain it will be missed, because developing software is complex. However, there is a difference in the results when it comes to treating the sprint backlog as a commitment, because the commitment is set by the people actually doing the work. The team can talk through how much effort something is going to take. The team knows what knowledge they have to shore up to get the task done. The team can investigate what dependencies or technical debt may hinder the development. So when the team makes a commitment, they have control over what they are committing to. As such, it is not artificial.

"OK, fine. We’ll bite. Why do we care about commitment? What does it matter?" you might ask.

First, commitment matters because if you are simply making a forecast and are not concerned with rolling work over sprint to sprint, then the sprint has no meaning. In this scenario, are you not just Scrumming your way through a Kanban?

Second, once the sprint has a commitment to fulfill, it spawns an array of improvements. The improvements are not necessarily in the efficiency of the execution by the Dev Team throughout the sprint. To that, the team will get incrementally better over time by the sheer nature of iterations and inspection. But in my experience, this small change in perspective made a host of other practices surrounding the execution fall into place — and, frankly, it made them more meaningful. This benefits everyone!

Some of the improvements I saw:

Protecting the sprint scope. If the possibility exists that the team might miss a commitment, it will be less laissez-faire about scope creep. People like to meet commitments. They couldn't care less about being right about a forecast (unless they're weathermen! And even then, I wonder.).

Protecting the team from distractions. If the possibility exists that the team might miss a commitment, it will be less careless about taking on work not in the sprint. Again, people like to meet commitments. Folks outside the Scrum Team will be less likely to ask the team to take on additional work, as they will now be stopping the team from meeting a commitment, and generally people don’t like to sabotage their coworkers.

More careful and accurate selection of work into the sprint backlog. If the team is accountable for meeting the commitment, the team will be more concerned with truly understanding the work they are accepting. People are not prone to setting themselves up for failure!

More focused retrospectives. The goal is to answer to one of two sprint outcomes: either "We committed to a body of work, and we completed it. What did we do right? What can we do even better?" or "We committed and missed the sprint. Where did we go wrong? What can we do to close the gap?" People like to improve, especially when there is a clear goal to achieve.

A more motivated team with a better feeling of success when the work is complete. According to the points above, it feels good to make a commitment and meet it. Plain and simple.

A more accountable ScrumMaster. I’m part of the Scrum Team. We’re all committed to these goals. If the team is not living up to their promises, I am a part of that failure. My concern and interest goes up, and naturally so does my performance.

A more confident product owner when communicating timelines. Product owners (POs), in turn, feel more secure in giving their commitments to stakeholders when they can in turn lean on a commitment made to them, especially when the team has a track record of hitting commitments. Let’s empathize a bit with the POs and give them as firm a footing as possible!

Believe me, I know and agree that there can be plenty of situations calling to keep the sprint backlog a forecast. But every situation, team, company, and project is different. If your team is having trouble gaining traction, feeling that their work has no meaning, wondering why it matters to discuss the sprints in retrospect; or if your POs need more data and resources to base their plans on — give everyone something to shoot for, and simply reinforce the commitment. It’s one small change that can bring a healthy amount of good without really much effort at all!
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (4 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe