Does the image below look and feel familiar? In 30 years developing software, managing organizations, and coaching Agile teams and organizations, I’ve observed and coached dozens of teams where overcommitting is a strong reality. I’ve seen sprint plans with planned velocities that were 2x or more than the team’s average historical velocity. In this post, we’ll explore some of the reasons why overcommitting happens and what it results in. Then in part two, we’ll cover what the likely root cause behind overcommitment is and explore some ideas to try to avoid overcommitting going forward. Overcommitting is not specific to any one company.

Three Behavior Categories that Lead to Overcommitting:

In my experience, I’ve seen overcommitment lead to three main behavior categories.

1. External pressure: strong need to satisfy a customer or product owner request; management pressure.
2. Internal pressure: desire to please others; hero mentality; need for individuals to “own” something (vs. team/collective ownership of deliverables).
3. Planning/capacity issues: unrealistic understanding of the work during planning; not taking individual availability/capacity into account; lack of prioritization.

It is worth noting that some of these behaviors, such as satisfying customers, are desirable and should be rewarded. But, they can lead to overcommitment if not balanced against what a team can realistically take on.

Key Symptoms When Teams are Overcommiting:

• Lots of Work In Progress (WIP):  A common trap for an overloaded team is that all (or most) of the stories committed to in planning are started 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 Agile is a team game and eventually collaboration has to happen. When it does, you may then see a lot of task switching across stories, across the team, only exacerbating the issue.
• Not getting stories to “Done Done”: 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 (DoD), which in turn could lead to technical debt and end-user issues down the road.

The Ultimate Results of Overcommitting?

• Lower quality: by not hitting DoD 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 irony is it has the exact opposite result. It actually slows things down.

Hmmmm… so why is that? Why does taking on (i.e. starting) more work cause us to actually deliver less? One answer to this question is how we think about product throughput vs. resource utilization. Are we concerned about getting out high quality products and services that our customers love faster, 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 Part 2, we’ll explore this idea further and I’ll propose some practical solutions to help your teams get to “Done Done” without overcommitting.