What to do if your teams continually miss their commitments

What should you do if your teams continually miss their commitments?

That’s a question I get all the time and it is a serious problem. Interestingly, though, the answer to this problem might not be what you think it is.

Sometimes people naturally think my teams are terrible at estimating or maybe they just don’t take commitments seriously. That might be true but there are some other things I suggest you investigate first.

By far the most common reason for a team continually missing commitments is they are being pushed to deliver or at least promising to deliver more tasks than they really can, and often where this will happen is when the product owner comes in with strong expectations about how much the team should commit to.

Sometimes the product owner doesn’t mean to influence a team this way, they might say something like, “Wow team, I’m really hoping I can get eight or nine stories this sprint”…

Bang… there’s the loaded gun right there.  The PO didn’t mean to shoot the team… it just happened.

Unfortunately, especially with a novice team, when they hear that, sometimes they hear, “Wow, we have to commit to seven or eight stories.” If that isn’t a reasonable amount of work, then of course they’re going to fail.

The first place you want to look to help teams that continually miss commitments is find out if they are feeling like they’re being pushed into committing to more than they really can deliver.

Another place you might want to do is check that the team are doing a good job getting acceptance criteria on every user story.  Is it clear, testable and measurable?

Perhaps get the PO to sit with the devs while they code the automates unit tests?

Acceptance criteria is the agreement between the team and product owner about what functionality needs to be included in a story to call it done.

If the team isn’t taking the time to get detailed acceptance criteria, in other words, they’re making assumptions about what the product owner wants, that can lead to problems later on when it turns out that the product owner really wanted something else. When that happens, stories have a way of ending up being much bigger than the team really thought they were to begin with.

Finally, one thing you should always encourage your teams to do is to look into the past to see what they’ve been able to deliver in previous sprints, before they make commitments for the next sprint.

Most of you will know that in Scrum we have a little pet name for that, we call it yesterday’s weather. That comes from the old adage, given no other information, the best predictor of today’s weather is yesterday’s weather.

Of course as the Scrum Master you have been transparent in your reporting and the team clearly knows their stats… story points and velocity. 😉

Given no other information, the best predictor of what the team can do in the second sprint is what they did in the first sprint.

For example, in the first sprint, if they committed to 50 story points worth of work but they only delivered 20, then what do you think they should commit to in the second sprint? Yep, about 20.  Sometimes teams get into this mindset of wishful thinking like… “Something bad happened last sprint but it won’t happen this sprint.”… something will always bit the team… every sprint… it’s the nature of software development.

Still, it’s better for them to rely on techniques like yesterday’s weather, what they’ve delivered in the past, to make commitments for the future, those will be the ones that will be most likely to be able to meet.

We hope you enjoy this agile tip. For more agile tips, please visit me at SteveRandall.com.au

Bring the spirit of leadership back.
Be Brave - Trust, Truth, Transparency.

Find yourself in this situation?  Give us a call for a chat. We love assisting companies and business leaders through this challenging time.

Steve: 0400 005 924 | 1300 851 861

#Leadership #HardButWorthIt.