Main menu

Enemies of Agile: Overcommmittttting

There are human traits which can lead us to bite off more than we can chew, to overcommit.

Optimism-bias
We tend to underestimate the amount of effort and/or time it will take to accomplish something.

Desire to please or impress
We like to tell people what they want to hear and deliver on our promises even against or in spite of the odds. We want to be heroes!

Dislike of uncertainty
We prefer certainty and generally dislike thinking deeply about the risks, what can go wrong or the potential deviations. We tend to focus on the “happy path”. Of course, some people are better at this, i.e. pessimists and QA and good Scrum Masters 🙂 They embrace uncertainty with open arms!

Why is overcommitting not desirable?

Well number one, it is a threat to a key Agile principle: “sustainable pace”. If you constantly overcommit, over time you may find yourself over-working in order to save face and deliver what you over-promised in the first place.

This can manifest itself at different scales.

At the sprint level: setting too many sprint goals, pulling in too many stories to a sprint.

At the story level: the story is too large to fit into a sprint and should have been broken down into smaller stories (as per INVEST guidelines).

At the release level: the backlog was sized but sizing was too optimistic and did not take into account the degree of uncertainty. Essentially the release plan was built on “hero estimates”.

This is not to say you should pad your estimates! That would break the agile principle of being transparent and open. Rather, the uncertainty should be given serious and deserving consideration and this should be expressed as a range. For example, a range of Story Points when sizing user stories and the backlog; a best case and “contingent” date when estimating a release (based on high level definition of scope only). This “shows your working” in that it represents your assessment of the inherent uncertainty. Resist the demand for a single point estimate. Keep in mind the difference between a “Target date” and the development team’s estimates. A target date is a single point in time and is something to aim for. Your estimate should give an idea of the likelihood of hitting that target at the time the estimate was given (i.e. estimates should be revised as you move towards the target – see Cone of Uncertainty).

Be on your guard. Be aware of your options. Stand your ground. Be brave.