Why We Care So Much About Sprint Commitments (and we hope you will too)

Every week, we set a sprint commitment for every project that we are working on. The sprint commitment is what we are committing to get done this week. It is what we think we can do this week.

Before we set the commitment, we give each issue that needs to be worked a complexity score. We also arrange the work that needs to be done from highest to lowest priority. We know how many complexity points worth of work a given team can do in a week. We combine this information to select the highest priority set of work that we can realistically do this week.

Why do we set commitments? After all, you have to take time away from other work to sit down as a team and make this declaration of intent.

There are really three broad reasons: pacing, focus, and planning.

Pacing: when you train for a marathon, it is important to determine your ideal pace.

If you run too slow in a race, that’s obviously bad. However, it is also bad to run too fast. When you run too fast, you deplete oxygen and fuel. You crash. You end up with an overall time that is slower than if you had paced yourself appropriately. It is the same in the world of software development. If you push the team beyond their ideal pace, they stress and overwork. You might get a lot done this week, but next week, the team’s production will crash. As a team working on your project, we don’t strive for maximum output in any given week.

We strive for maximum output over the life of your project.
This requires sustainable pacing.

When we are pushed to accept an unrealistic commitment, I always think of a project where we messed up and broke our rules. We got pushed to commit to about twice as much work in a week as that team had ever done before. None of the stakeholders other than the development team would give an inch. We caved, and put our nose to the grindstone, and committed to shipping twice our sustainable pace.

The next week, one of the two developers went out sick for days. A couple of weeks after that, the other developer left the company– which was shocking, because our turnover over the last five years has been almost zero. It took the project months to recover to a normal pace again. In the end, over that span of months, we got far less work done than if we had stuck to a sustainable pace throughout.

Secondly, focus: it is important that Software Engineers primarily focus on the current work that needs to be done.

If there are things in your commitment that don’t need to be done now, they are distractions burning mental cycles. With an unclear or oversized commitment, there will be ambiguity about what gets built first. If there is no commitment at all, your entire feature backlog is on the team’s mind. That could be hundreds of issues, ambiguously swirling around and taking the team off task.

Software Engineers build software, and they also help plan future development efforts. With a clear sprint commitment, no one is trying to do both at the same time.

And then, planning: a sprint commitment tells you which features and bug fixes we intend to ship this week.

This helps you to plan all sorts of things. What is going to be available for the big demo on Monday? When should we schedule that big marketing push? When do I need to sit down, gather my user feedback, and start planning the set next of features? Will this feature be done before I go on vacation, or do I need to hand off that work to someone else?

When problems arise with sprint commitments

Sometimes, clients push us to accept a commitment that contains more than we think we can really do.

“Committing to more than we think we can do” is a nonsense phrase, like “dry water.” We don’t differentiate between “what we think we can do” and “what we promise to do.” We only make promises we think we can keep.

I think our clients sometimes push to add more to the commitment because they feel that if we commit to more, we’ll get more done. Well, we’re already running at our maximum sustainable pace. I could promise you more than that, but I’d be lying to you and putting my team at risk.

A thing I say in these situations is “I can disappoint you now, or I can disappoint you on Friday. I’d rather disappoint you now, live honestly, and deliver what we promised on Friday.”

From time to time, a client will push for more and say “but it is OK if you don’t deliver it.”

This doesn’t really change the situation. You are just saying “but it is OK if the water comes out a little dry.” If we don’t believe we can deliver it, it isn’t part of the commitment. We’re working as fast as we sustainably can, and we’ll work on those things just as soon as we finish these things. We’re not going to stop working just because we hit our commitment. We pick up the next priority and keep going anyway.

So why corrupt this valuable guide star? Why add distractions that we don’t need to worry about yet?

I’ve found more often than not, that no matter what someone tells you at the beginning of a week, by the end of the week they want to see that whole list. That’s why they put that work on the list. I’d rather disappoint you now.

Sometimes, clients even say “but I don’t care about the commitment.” Firstly, I question whether that is true deep down. It’s hard for me to imagine someone paying a significant amount of money to have a problem solved, and then not caring when that solution ships, or even which parts of the solution ship in which order. And even if a client truly does not care about the sprint commitment, we care.

We still need the pacing, focus, and planning of a sprint commitment.

We’re always evolving

We are experimenting with a revised process. In our pilot program, we aren’t manually setting sprint commitments with the team. Instead, all of the features and bugs which need to be worked on are listed in priority order in our backlog.

Each issue has a complexity score, just like in our current process. At the beginning of the week, we automatically commit to the top X points, where X is the sustainable pace for the team. If we get that done by Friday, we win. We have several goals with this experiment.

First, we still want to maintain the pacing, focus, and planning effects of the current sprint commitment process. However, setting the commitment automatically forces us to have our user stories, prioritization, and complexity score processes running well ahead of the development team. This means it is never unclear what the team should be working on– even first thing Monday morning. And it saves the time of a special kickoff meeting. Overall, we believe this will lead to an even higher sustainable pace for our team.

I hope that explains why we care so much about sprint commitments and why we want you to care too. If you would like to connect and chat, reach out to me on LinkedIN.

---

Lean Agile Process Product Management Sprints