Does this look and feel familiar? Overcommitment seems to be a reality in a lot of organizations today. I’ve personally seen some sprint plans that had planned velocities that were two or more times the team’s average historical velocity. In this post, we will explore some of the reasons why overcommitting happens and what results it actually produces. Then we will cover what is likely the real root cause behind overcommitment and some ideas to try to avoid overcommitting going forward.
Overcommitting is not specific to any one company. In 30 years of developing software, managing software organizations and coaching Agile teams, I’ve seen it over and over again. In my experience, there are three main categories of behavior that lead to overcommitting:
- External pressure: The customer, Product Owner or management have made it clear that the deadline and/or deliverable are non-negotiable.
- Internal pressure: Individuals desire to please others, have a hero mentality, or a need to “own” something—versus aspiring to team/collective ownership of deliverables.
- Planning/Capacity issues: This is rooted in a lack of real understanding of the work involved during planning, not taking individual availability/capacity into account, and/or a lack of prioritization.
It is worth noting that some of these behaviors are desirable and should be rewarded: customer satisfaction is always the ultimate goal. But, these types of behavior can lead to overcommitment if not balanced against what a team can realistically take on. As a result, everything and everyone involved gets a little less love and a lot more stress. Overcommitting means attempting to fit too many units of work into an iteration. The team realizes overcommitment when the end of the iteration comes and there’s still stuff on the backlog, stories that are blocked. How many units of work or slices of value a team can deliver depends on the team, therefore each team’s definition of overcommitment will also be different.
Why is Overcommitting Such a Bad Thing?
You may wonder, “So what if me and my team overcommits? What’s the big deal?” The ultimate results of overcommitting, however, in my experience, do amount to a decent-sized deal. They include:
- Lower quality: by not hitting Definition of Done on each story every sprint.
- Team and individual burnout: teams and individuals go into hero mode, which is neither sustainable nor scalable.
- LOWER overall productivity: paradoxically, teams overcommit to get more stuff done faster, but the reality is it has the EXACT OPPOSITE RESULT: It actually slows down productivity.
Why is Does Overcommitting Slow Down Productivity?
Great question. Why does starting more work cause us to actually DELIVER LESS? Well, one answer to this question is how we think about product throughput versus resource utilization. Are we concerned about getting out faster high-quality products and services that our customers love or are we concerned about making sure every single employee is “fully utilized”? I would maintain we should be much more concerned about the former and much less concerned about the latter. In other words, am I more concerned about the baton making it around the track or about all of my runners running 100% of the time? (If you’ve never been one for watching relay races, it’s a trick question.)
A typical metaphor used to illustrate this concept of product flow versus utilization is a freeway. We all know what happens when a freeway is fully utilized: gridlock. The same thing happens to teams; you just can’t see it so clearly. Some other observations about how freeways work that map to teams include:
- The actual rate at which a highway slows down increases dramatically as utilization increases. Traffic slows down much faster at 80-90% utilization.
- When traffic incidents occur (accidents, lane closures), the impact is much higher at times of high utilization.
When a freeway is at or near maximum capacity, its ability to handle the unexpected decreases significantly. The same principle applies to software teams. There are a host of unknowns, random events will occur, so our plans need to have enough slack in them to account for these. If we focus on maximum utilization, our teams will start to thrash when things don’t go exactly to plan. At maximum utilization, in the event of the unexpected, you’ll have to triage, to decide which systems to interrupt and how to account for the consequences. And by the way everything—the decisions, the meetings, the triaging, the interruptions—cost money, time and resources.
What Are Symptoms of a Team Overcommitting?
What happens when teams overcommit? Some key symptoms include:
- Lots of Work In Progress (WIP): a common trap for an overloaded team is for all (or most) of the user stories committed to in planning are started on at the beginning of the sprint. The thinking behind this is typically: “Hey we got a lot of work on our plate to finish in two weeks, we better get started on ALL of it ASAP.”
- Lots of Task Switching: All of that WIP then leads to a lot of task switching. A team may initially think they can avoid this by assigning stories to specific individuals, but software development is a team game and eventually collaboration has to happen and that will cause a lot of task switching across stories across the team.
- Not completing stories at the end of the sprint: Ultimately the previous two symptoms lead to not all stories getting to “Done Done” by sprint end. Something gets compromised: either some acceptance criteria are not met or the story doesn’t meet the Definition of Done, which in turn leads to technical debt and quality issues down the road.
10 Tips for Focusing on Delivery
Instead of focusing on utilization, let’s focus on delivery. Let’s get stuff done (with quality) before we start working on new stuff. One way to do that is by ceasing to overcommit starting now.
To avoid overcommitting in the future, here are some ideas to try with your teams. Don’t feel like you have to do all of these, just pick a couple to try and see if they help. If it doesn’t help, try something else from this list.
- Use “yesterday’s weather” (i.e. your team’s average velocity) to sprint plan what you can take on in the coming sprint.
- Actively manage your team’s WIP during the sprint. For Kanban teams, this is done through WIP limits, but even Scrum teams can put WIP limits on the number of open stories your team is working on at any given moment.
- Focus on getting stories to done as quickly as possible before starting new stories.
- Swarm (or at least pair) on stories to get them done faster.
- Allow for slack time in your sprint plans. This will better enable your team to handle the unexpected and maximize the flow of delivery.
- If you’re concerned that your team may not have enough work coming out of sprint planning, then have 1-2 stories in the ready queue to be worked on if in fact the team finishes all the committed work before the sprint ends. You can always pull work into a sprint before it finishes.
- Keep your stories small. Queuing theory provides evidence that small items flow through delivery systems much faster than large work items.
- Make sure your stories are READY to be worked on before sprint planning. This will lead to better understanding of the work, better estimates, better planning overall. Many organizations I have worked with have developed a Definition of Ready for guidelines on what a ready story looks like in their organization.
- Make sure you know everyone’s true capacity for the upcoming sprint during sprint planning. Make sure you call out everything that takes time away from capacity, including time off or upcoming events you need to be prepared for.
- Make sure that all your team’s work is identified in planning and is visible during the sprint.
So in your next few sprints, try focusing more on finishing and less on starting work. It really will make your work life easier, produce higher quality product and actually get more product out the door faster that our customers love. Isn’t that why we are all here in the first place?