Promise Less for Better Sprints

We all do it from time to time: over-commit and under-deliver in sprints.

In our work as Agile coaches, we at BERTEIG often encounter teams that are not able to meet their promises at the end of each sprint.

Often, teams use a points system to make their estimates of how much they can commit to in a sprint. It does take a few sprints to find your actual pace. Even once they do, they still end up over-committing.

And it’s a big problem.

If you’re coming from a waterfall way of doing things, there’s not the same kind of urgency mid-stream. But it feels urgent at the end when everything gets integrated.

What we want to do is unburden ourselves from that big stress at the end of a project and instead, split it up and do lots of little projects.

It’s a lot easier to deal with. You get to go home on time. You have the weekend to yourself. It’s a good thing.

Having said that, it’s still not easy in the beginning. I don’t know if anyone ever thought that Scrum would be easy, but it’s not. However, when you get it right, it’s very satisfying.

But even in Scrum, people still end up over-committing.

They’ll commit to a certain amount of work for a their sprints and then it doesn’t get done. Either some things don’t get started, which is perhaps a better problem to have. But maybe all of those things get started that they’ve committed to and some of them don’t get completed. That’s a problem.

There may be several things going on here.

Lack of Urgency

The team just doesn’t yet feel the imperative to get something done by the end of the sprint. There’s nothing outside of the team making it important. So if it’s not important, why do it?

Gigantic User Stories

The size of the user stories the team will commit to are too big for their sprints. That’s a habit of working in a waterfall fashion. There was no pressure to speed things up in waterfall. You just do it till it’s done.  

But in Scrum, there is some pressure to speed things up and make them small so that they fit into the sprints.

When you commit to smaller stories, they are…

• easily understood
• easier to estimate
• more likely to be finished without an interruption
• easier to do within the team itself without external help

Even though you at the end of your sprints, you’re left with way more items with more stories in your product backlog, splitting them all actually makes them easier to complete.

Once they’re smaller, the ability to estimate accurately or commit becomes easier in the next sprint.

When teams first implement Scrum, they take these great big stories, don’t split them up and don’t get them done at the end of the sprint. So they get carried over. If a team gets 75% of its commitment done, they might think that’s fine. But it’s not.

So when I go in and coach, I ask a bunch of questions and one of them is why didn’t this get done? And it’s that they just couldn’t get through at all. But they didn’t see a way to split the story up because everything’s connected.

There are lots of ways to split a story.

The most common way is the CRUD acronym:

• Create
• Read
• Update
• Delete

There are many other ways too.

Whichever technique you choose, splitting the story is really important. Not everyone is comfortable with that in the beginning because it feels like it’s incomplete until those three or four parts are done.

And while that’s true, nobody says that you must release something every sprint. Scrum says “potentially-releasable product”. It just might be useless. It might not be something that anybody would pay for yet, but it works.

The reason that teams over-commit is rooted in project fallacy: a team being overly optimistic. The assumption when you make your estimates is that nothing will go wrong. If you’re splitting it into much smaller pieces, it’s a lot easier to actually know what could happen.

Then you’re being realistic and you don’t have to guess and be optimistic.

Developers are nice people.

They want to help the organization. They really want to get it done. And then reality gets in the way. Ideally we’re working on fewer things without interruption to get it done.

Sometimes, the organization hasn’t adopted this idea of working in short cycles and so they keep pushing stuff on the team rather than looking at it realistically. We talk about this in our Certified ScrumMaster course, when we discuss the Iron Triangle:

• scope
• time
• cost

You can have two of those things, but not all three.

Once we know how much we can do in a typical sprint, we can make projections. We can either commit to doing a certain amount of work by a date, or tell you how long it’s going to take to get a certain amount of features complete.

Another challenge arising from stories being too big is demonstrated in the burn down chart. It kind of looks like the typical hockey stick where very little gets accomplished until the last day or two and then the line drops precipitously.

This is working in a waterfall way.

Why does that happen?

It’s because they take on so much and they deliver it in a 10-day sprint. But development might take six or seven days to complete and then they hand it over to the QA folks to test. And if they find anything, they’ve got to quickly fix it.

As a coach, one of the fixes I implement as a team rule is if the QA team works late—which is not uncommon in the beginning—then everyone stays late until they’re done. It’s a simple but really effective tool to help people change things.

Stop starting. Start finishing.

Let’s say a team commits to 10 items but they actually started eight and finished eight at the end of the sprint. That’s good. It’s progress, because they haven’t left something hanging. That’s actually better progress than getting everything they committed to mostly done or almost done, which is really nothing done.

Now they have options at the end.

They can obviously move those two items and do them in the next sprint or maybe they’ve learned something and they won’t need to do those two things at all. Or they just get reprioritized.

The practice of making something small and getting it complete at the end of the sprint is the goal here. It’s not so much trying to complete a lot of stuff. That’s good too, but it’s better to finish what you started to a high level of quality because then you’ll learn what you what you are actually capable of doing.

The business side of organizations actually prefers predictability over getting everything almost done.

If you find this useful, please consider contributing with our
“Value for Value” model.