Using retrospectives to deal with sprint failure

It’s always an awkward situation when a team fails to deliver a sprint backlog they committed to. Feelings of disappointment, frustration and failure are flying through the room. As a team member, how would you handle this? Ignore it? Start discussions? Focus on the next sprint?

I always found the retrospective an ideal moment to deal with this. The open atmosphere and clear intentions of the meeting make it easier to talk about failure.

How do we typically address this?

We start with creating a timeline on which all events of the previous sprint are mapped. This helps the team to think about the previous weeks.

Then we start with an overview of the sprint velocity. How much was delivered versus how much was committed to? This remembers everyone about the goal of an iteration which is to complete the sprint goal that we planned together.

Our next step is to come up with a list of things that could have influenced the team velocity. Here’s an example:

  1. “We needed to set up an extra demo environment.”
  2. “User story 4 needed extra discussions before we could start.”
  3. “User story 5 was cancelled half way through and replaced by another one.”

Then we put a rough amount of time on each one. The sum of these often matches the gap in velocity pretty closely.

The final step is to identify how we can prevent this from happening again. Here’s an example for the previous list:

  1. Include the set up in the sprint planning and get it estimated or time boxed.
  2. Don’t include user stories in the sprint backlog that are not ready.
  3. Don’t include user stories in the sprint backlog that are not prioritized and validated by the customer.

Quality planning and minimizing team interruption will solve a lot of these issues. And if you’re able to remove as much dependencies as possible, delivery will be much more consistent.

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: