Dealing with Reality and Adjusting Sprint Commitments

Okay, so…you have a plan. Your Agile team had a successful Sprint Kickoff, and everyone has agreed to the Sprint Commitment. The team is pumped and can’t wait to get started…

And then, something happens. You name it: a firedrill on another project’s production app, a team member falls sick, someone’s computer chokes on an OS update. Or maybe one of your stakeholders uncovers what might be a show-stopping bug or a compatibility conflict. What now?

If you’re like many teams, you may just shrug and say, “Shit happens. We have our Commitment, and we’re moving ahead.”

Maybe that’s okay, but I think you can do better: for yourself, your team, and your client. It’s time to figure out how to adjust your sprint commitment.

Always deal with reality.

Let me ask you a question. You are cruising down the highway at 70 mph (70? really? be honest here — you’re trying to go 85, aren’t you?) and you see steam rising from under the hood. What do you do? Do you grip the steering wheel, put your head down, and push it up to 90?

No, you slow down. You pull over. You might even check your bank account once you’re on the side of the road, before you decide between calling for a tow or waiting for a Good Samaritan.

Why? That’s your reality, and you’re dealing with reality.

Adjust a sprint commitment by facing it head-on.

Okay, so your Sprint blew up this week. It’s Wednesday afternoon, and you’re looking at the status of your one-week sprint. You’re nearly 60% through the Sprint, yet not a single ticket of the seven you committed to on Monday have made it to QA.

Is it time to freak out and really rev up the RPMs? No. In software, just as on the road, you pull over, and you pause.

Name the problem.

Make your status known to the greater team, and you’ll find that many times, help will arrive. You’ve thrown out some road flares, and alas: a Good Samaritan will appear.

Pausing to assess the sprint will sometimes mean making an actual change to the Sprint Commitment. Gather the team, include the Product Owner, and have a real discussion about what can still ship this week. Your team may choose to put tickets back in the Icebox. Or you may choose to leave them in the Sprint, but with the shared knowledge they will likely remain on the board for next week.

Focus on the critical commitments.

If there’s something that is mission-critical to ship, adjust the Sprint Commitment. Re-focus efforts, find a pairing partner, and ship that story. Everything else might be a distraction at this point.

Sometimes you need to slow down to speed up.

Most people do not like to miss a commitment — in life, or in software development. But if we are moving fast, and if we are motivated by setting aggressive commitments, we are going to hit speed bumps.

Isn’t it much better to deal with reality? Isn’t it better to find something valuable to ship instead of nothing at all?

Originally published at revelry.co on March 29, 2018.