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:
- “We needed to set up an extra demo environment.”
- “User story 4 needed extra discussions before we could start.”
- “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:
- Include the set up in the sprint planning and get it estimated or time boxed.
- Don’t include user stories in the sprint backlog that are not ready.
- 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.