Is your Agile Team Overcommitting?
As a delivery coach, I go to a lot of Sprint Planning, and a recurring pattern always gets played in the sessions. Well-meaning teams rock up to their Sprint planning sessions, and the team overcommits to the number of stories they can do without knowing they have bitten more than they could chew.
Shortly after that, they enter the Sprint, bright-eyed and hopeful that this will be the Sprint they meet their velocity.
Sadly, they were doomed from the beginning, and you guessed it — this Sprint was not to be. The team only manages to complete some planned stories, leaving them confused.
How could it all go so wrong? Maybe, the next Sprint will be different! Yes, Let’s try again.
And the same movie keeps playing in a loop every Sprint planning.
Sound familiar?
This team’s behaviour of over-committing in Sprint planning is an anti-pattern. Anti-patterns are common reactions in response to a problem, thinking these actions will resolve the issue when in reality, they end up doing us more harm than good.
So how do you spot and help a team who are notoriously overcommitters?
Let me talk you through some scenarios, and together, we can try, and your teams, to do better Sprint planning sessions in the future.
1. Your team has spillover stories from the previous Sprint
During the Sprint planning, your team commits to the targeted stories for the Sprint. However, you also have spillover stories from the last Sprint, which is equally important. So your team commits to the spillover and targeted stories of the next Sprint.
As a result, your team unknowingly overstretches themselves in the next Sprint and inevitably only completes a portion of the committed stories.
Try this:
If your team is spilling over stories to the next Sprint, likely, they need to be sized up correctly.
Either the effort was much more than expected, but the size given by the team was small. Or the story size and effort were too big to finish in a Sprint, which needed to be broken down into smaller stories.
As a rule, I keep my sizing range of Fibonacci in a small range. No infinity or 100s. I like the range 0, 1, 2, 3, 5, 8, 13, 21. No more than that. I expect stories of size 1 to 3 to get done relatively easily and quickly within a Sprint, and the 5 to 8 may take most of the Sprint. While sizes 13 to 21are big stories which need to be broken down further into smaller stories.
I don’t recommend committing to a 13 or a 21in a Sprint planning. These are guaranteed to make spillover stories to the next Sprint. I would break a 13 or 21into smaller stories and then commit to them in Sprint planning.
2) You have a superstar team member who says they will be able to do x number of stories tonight or in a few overnight sessions.
Your team has a highly experienced, highly reliable person who can do everything. All team members rely on what they say during the planning and commitment session.
Of course, they always overcommit because they’re only one person and overestimate what they can do in a few late-night bash-the-code sessions.
Try this:
Whilst it will take time, we need to invest in shadowing this superstar to start delineating and allowing others to do some of the work to learn.
Most of the time, we build other team members’ confidence and skills so they begin to believe they can do the work, which may take a bit longer than the superstar, but that is ok.
For example, if a superstar might estimate a solution or task as a size 2. The other team members newer to the task might take a 5. We must respect that the story is a size five and include that in the total number of stories.
In addition to shadowing, there’s an element of expectation management here as the superstar team member might think it’s their team and that they are not a team member but rather the owner of that team.
As a coach, give that superstar a team-oriented goal, not just a mandate to do what they do because they are awesome. With a team-related goal, they will feel like they are part of a team.
For example, a goal could be — to help raise the quality of the work through code or help drive the team members through knowledge transfer so they can focus on the more complex problems.
3) Your team is optimistic about the number stories coming in for the Sprint and wants to commit to it.
You get to the Sprint planning, and team members are upbeat about committing to their stories. They could see no problems or challenges on the horizon.
They don’t believe in their past velocity; they reckon they could do more as they feel positive. There is also that extra push from the sponsors of the project.
Inevitably, the Sprint comes and goes, and the team completes only a tiny portion of their committed stories.
Try this:
In Scrum, we measure and size for a reason. Always use data and err on the cautionary side.
Follow your team’s average velocity, and have the extra stories your team thinks they can commit to lined up and ready to be picked up once they’ve completed their commitment.
If you think the data is no good, start feeding it good information. Good information does not mean making your team look good with the data. It means reflecting on what really happened in the Sprint through data. Simple things like ending your Sprints on time, counting the number of completed stories, and sizing them up correctly (this one is big and probably warrants a separate post).
If you start cleaning up your team’s data, you can rely on it rather than depending on your team’s hunch.
4) Your team is not refining stories, well, not really.
What’s a clear sign that your team needs to refine stories better? That’s easy. Look at the backlog right at the top. Stories in there should have been sized and small enough to manage in a Sprint. If it has infinity, 100, 32, 50, or some random number, then that’s a clear sign that this team isn’t spending time refining it.
Solution:
Sadly, many Scrum teams fall into reactive mode once the Sprint begins. They may think the busier we are bashing code, the better we will be by the end of the Sprint.
In addition to that, executive sponsors want to see the same thing. They want people to look frantically busy so that it looks like things are getting done quickly!
You have to put some time into your team refining the stories. This is a must. Otherwise, your team will be beavering for the sake of beavering. You also have to get the support you need from the people required for the stories to clarify or act on it. If not, then there is no need for the story or the priority of the story to move down, which needs to be communicated to the stakeholders.
Let’s check out an example. A story in your backlog has been blocked for many sprints because it’s dependent on a DevOps environment needing to be created by the DevOps team. The story is a sized 32 or something random (big). Your team does not even know how to get this started. They know that a big part depends on a DevOps environment.
The first step is to divide this story into bite-size pieces. Think of the following questions that could help break this story down and get it appropriately sized:
- Is there a functional piece to this work that can move along? Can you de-couple them?
- Is there a trade-off that your team could do if you move along with an approach while still waiting for the environment?
- What are the risks?
- Can it be managed and communicated?
Your team needs to ask the tough questions to break stories down to produce valuable stories and differentiate them from technical tasks.
5) Someone else is committing to the stories for the team.
You get to your sprint planning, and you sit quietly. The PO rocks up and assigns everyone their story!
I’ve seen this done way too many times by well-meaning Product Owners who starts to command and control the whole Scrum team, and it doesn’t work. Poor Scrum team members are left disgruntled and scared to disappoint Mr or Ms Product Owner. This approach leads to overcommitment and failure to meet their team Sprint goals.
Try this:
Only the doers can size and commit to the work because they’re the ones who will get their hands dirty. This is their right.
We need to provide a safe environment for our team members to feel they can own the work and safely estimate without being judged by the stakeholders.
In addition, we need to set the roles and responsibilities right and talk about the disruptiveness of having other people assign stories to the Scrum team. In most situations, Stakeholders tend to result to command in control because they fear that the scrum team may not deliver or isn’t performing to their expectations. In this situation, we must hand-hold our stakeholders and work together to manage their expectations and worries.
There you have it! Have you seen these patterns in your teams? What have been some of the most effective ways that helped your team avoid overcommitting to too many stories?
