Failing sprints? Decompose your stories to the nth degree

Dive Off by Sebastian Mary
Is he about to fail his sprint? Image by Sebastian Mary

Recently I had a retrospective with one of my teams after two failed sprints. They cited unplanned tasks as one of their issues and suggested that perhaps the scrum framework wasn’t right for the kind of project they’re currently doing.

To give some context, this is a long running team on a long running project with no kind of release windows. One mistake that we did make was that there wasn’t a ‘Sprint Zero’; a chance to look at the project as a whole and do some time-boxed up front planning for a sprint. However, we’ve entered two sprints without some knowledge of how we plan to do things and it’s caused bad sprints.

When we began to plan the current sprint. There were some ‘technical’ stories in the backlog, for large chunks of backend work which had other stories dependent on them. They were all estimated quite high, without acceptance criteria or the ‘As a …, I need …, so that … .’ stanza to support them. This is fine, the stanza is only important when it provides value and usually not for technical stories. One of the problems was not having acceptance criteria, so the first thing we did was to define those.

After that and to get to the crux of the post though, I asked :

Describe this story in high-level steps.

To which the team discussed what would be done to do each story, we defined the tasks at a high level (much like you would do when planning proper), but after each task was defined, I asked the team to estimate the tasks in story points. It was an eye-opener!

The tasks were all coming in with estimates of 2’s and 3’s. Which meant that, when the broken down, estimated tasks were added up, they were more than the original story. This usually happens, but it was an ‘Ahha!’ moment for the team. It allowed them to think more abstractly about the work. It’s not the plans that are valuable, but the planning!

To compound the issue, we’ve been getting hung up on the idea of each story delivering functionality which we can demo. While this is a noble goal, I’m sure it’s not always possible. This was causing huge estimates on stories and, as we know, bigger estimates mean lower accuracy on that estimate. With this constraint removed, the team breathed a sigh of relief and began writing stories which were meaningful and well sized. What actually came out of it is that, once we’d broken them down, we could see that for some of them, there actually were things we could demo; speed improvements on database queries and data integrity which DO provide value and so can be demoed.

Finally, when choosing the stories to add to the sprint, the team committed to work which they used their gut feel (and their velocity, but only as a guide) on what they could fit in. I went through each story asking, ‘Can we do this and all the previous stories?’ They committed to less than they would have had they just added the original stories. Meaning that, the non-decomposed stories were causing them to overcommit without recognising it.

So, if you’re failing sprints due to unplanned work cropping up and causing you to have over-committed, then ask for high level tasks on how to complete the story and estimate each of these tasks as if it were a story, you can go too far by decomposing each task to a story level, but if you’re finding this is the case, then your failed sprints probably aren’t caused by your stories.

Guessing a velocity

You’re at sprint zero. You’ve got a new team. You’re new to scrum. You’ve never quite managed to stick to the Scrum framework. All reasons why you might not have a velocity. I’m sure there are more, but these are the most common. What do you do? How do you know how much you’re going to be able to fit into a sprint?

You guess.

Yes, I’m serious. If you’ve groomed your product backlog for the first sprint, estimated your stories and refined those estimates and broken down larger stories, then the only thing left to do is guess. Gather your team around and ask them “What do you think you can fit into this sprint?”. Once the team has picked from the highest priority stories and agreed that they think they can fit the work in, ask for their commitment. It’s at this point that you’ll need to help the team decide whether or not they’ve over committed. Most teams almost always start out thinking they can deliver more than they really have the capacity for. It’s not because they’re showing off, or because of any kind of arrogance, they actually do think they can deliver what they’ve said they will. Remind them that, while the stories are well written and the acceptance criteria well defined, they are just the start of a conversation with the business and things could change.

Your team will probably decide to knock of one or two stories and right now, that’s fine as they can always go back into the sprint if you find yourself running out of stories half way through. Once there’s a commitment, add up the story points. That’s your predicted velocity. It may not be accurate and it’s quite probably wrong, but right now, right this very minute it’s the most accurate idea you have of how much you can deliver in your sprint.

Why is this useful? Well, it will give your team a target, they’ll want to actually hit that velocity prediction as they’ve said they would. It’ll also come in useful for release planning and having some kind of vague idea of when your product might be delivered. You know least about how long or how complex a task is right before you start it, but now you’ve got some benchmark. You can add up the rest of the story points on your backlog, divide by the predicted velocity and have a figure which is roughly how many sprints you’ll need before you have delivered your product.

That is something that the product owner will shit himself with excitement about. Assuming he hasn’t asked you to translate that into a gantt chart.