Overcoming Sprint Overcommitment problems – some practical tips from a practitioner

Most teams face the problem of overcommitting during Sprints early on in their formation. In coaching four teams concurrently, I have done a fair bit of work lately to overcome overcommitment.   

Overcoming overcommitment starts with an honest reflection of yourself. “You’ve bitten off more than you can chew,” I can almost hear my mom saying it. It means you’ve taken on a task or responsibility that is too difficult for you to handle. Overcommitting is often not deliberate. But even with the best intentions, overcommitment derails predictability and productivity. People get frustrated, burned out, or leave the company. To prevent that, get everyone involved in solutioning. 

When I talk about Overcommitment, also known as 'Spill Over' and 'Carry Over', it all points to a team that has taken on more than it can handle. While overcommitting can be a big problem when it comes to achieving the predictability that the business/product owner craves, it also presents an opportunity for the whole team to come together and work more effectively. 

To tackle overcommitment, I have found that letting data drive decisions, defining before we refine, and monitoring work in progress (WIP) are critical. Here are a few lessons learned on each of these. 

In a complex world, I rely on metrics to bring transparency, simplify decision-making, and drive solutions. Ratios, like the Complete-to-Committed ratio, are especially useful. They help you analyze challenges from both sides of the equation and find a balanced approach to moving forward. My teams use Jira for their source of truth. Jira’s canned reporting, like a Burndown Chart, Epic Report, and Velocity Chart are pretty good on their own. To see how much work a developer has on a Scrum Board, I created Quick Filters and swim lanes. In Daily Scrum, we can have a productive plan for the day. For example, by using the Quick Filter we can see a developer assigned four stories and three defects. We then can have a conversation regarding priority and who can help take some pressure off a single developer. It gives us foundational visibility into the work that can and cannot get done.  Having one version of the truth is something I work to establish every time. 

Then it is best to “Define Before You Refine”. Recently I ran a Refinement Workshop with one of my new teams focused on complexity, testing, and how many people it would take to complete that user story. I have found this to be a useful initial step to take with every new team that I work with. I’ve facilitated dozens of these over my career, and it is always surprising just how diverse everyone’s opinions are at the beginning yet aligned at the end! In this case, we aligned on a pointing strategy, helping everyone understand what a 1-point story entailed versus a 2-point story versus a 3-point story, etc. We determined that 8-point stories couldn’t be completed within a single Sprint and would need to be split up. We also defined what we meant by Sprint-ready. This definitional alignment—splitting stories, discussing their size, and determining if they were Sprint-ready—helped us commit to the correct amount of work during Sprint Planning. It was a simple shift that made a big difference in managing the team’s workload effectively.   

Across teams I work with we establish a work-in-progress (WIP) limit of 1 element of work per developer in the sprint. The phrase “in parallel” is taboo; it means that the developer doesn’t have complete focus. Instead, developers move their work to done and connect with other developers to help move their work to done before picking up new work. Their primary focus is on the work of the sprint to make the best possible progress toward these goals. I work with everyone to monitor this and keep to our WIP commitment, context switching is a productivity killer, which in turn keeps us from overcommitting. 

I’m always learning ways to improve the outcomes that my teams produce, I hope you have learned a new trick or two from this blog.