Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 05, 2008 — Enterprise Agile Planning expert

When Under-Commitment Is the Order of the Day

Enterprise Agile Planning

How much your team is willing to commit to during any Sprint is going to depend on a lot of things, starting with how comfortable your team is with not achieving all of the planned results. Many Scrum teams will deliberately under-commit because they work (or are under the impression that they work) in an environment that frowns on not achieving their objectives as stated. This is a pervasive problem in business today; we all work (or have worked in) environments where you make estimates, you make objectives based on those estimates, and then you’re stuck achieving those objectives, even when the estimates were flawed (which they usually are) or the business circumstances changes in unpredictable ways, affecting our ability to achieve our objectives. Unfortunately, this type of business promotes individual agendas that often conflict with organizational goals, result in employee overwork (which invites burn-out, clinical depression, neglected families, and reduced product quality), and engender creeping mediocrity.

In the Agile Development environment, under-commitment occurs during Sprint Planning when teams either deliberately over-estimate items or deliberately under-commit to their Sprint goals. As mentioned before, teams do this because they anticipate unwanted consequences when they don’t achieve all of their Sprint Goals. In one example, a manager decided that an important measurement of his Scrum teams’ productivity was the ratio of completed stories over committed stories. Therefore, if his teams completed only half of what they committed to, the measurement would be 50%. Obviously then, completing everything that was committed to would result in a measurement of 100%. The manager thought that this measure was both useful and would help his teams work toward completing the stories they committed to. What actually happened was that productivity dropped as the Scrum teams deliberately under-committed Sprint after Sprint. Even worse, when team members had time at the end of the Sprint, they absolutely would not take new work from the Product Backlog because that would introduce the risk of not completing a story which, of course, would “mess up” their metrics.

Teams either finish their goals during a Sprint or they don’t. Sprints begin and end on pre-scheduled dates that have nothing to do with how long stories on the backlog will take to be finished. There will be many reasons for teams to not finish all of their goals from a lack of experience on the part of the team members to organizational dysfunctions that result in inefficient work patterns to, as mentioned earlier, time simply ran out. There’s nothing good or bad about not finishing all of the items that a team committed to – it simply happens.

Clearly, we need to take a completely different approach to setting and reacting to Scrum team goals. We need an environment that encourages aggressive, achievable commitments while removing the stigma of failure related to not getting all of the team’s commitments completed. Teams need to be encouraged to be reasonably aggressive with their commitments during Sprint Planning and to continuously take steps to improve team performance. As the Sprint progresses, if it seems likely that a team cannot complete all of the stories that they’ve committed to, they need to be permitted to return the lowest priority items to the backlog and reduce their overall commitment.

Of course, having said all this, there is always that case where a team doesn’t finish their Sprint goals because they actually did not work in good faith with the organization. They, to be blunt, slacked off. Some would suggest that this is the reason why measurements of Scrum team progress are so important – to quickly identify and deal with situations like this. However, as common sense suggests, if a team is truly not working in good faith with the organization, the signs would be everywhere without having to be specifically measured. Observation of team activities during the Sprint, the progress reflected by the Sprint Burndown, the results demonstrated during Sprint Review – all of these will show evidence that the team is not performing to their capabilities. Should this be the case with any Scrum team, some radical changes in the make-up of the team, up to and including disbanding the team entirely, would certainly be called for.

Download the PDF version: When Under-Commitment Is the Order of the Day blog

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us