I subscribe to Mike Cohn’s newsletter, and I received a post on January 20th, 2022 entitled—

7 Reasons Teams Underestimate Work

It was quite short but sweet and valuable. I’m sharing his list of seven factors below.

  1. Overconfidence

  2. Lack of clarity about the feature

  3. Estimating a best-case scenario

  4. Multi-tasking is not considered

  5. They aren’t including time to iterate

  6. Not all work is included

  7. Assuming they’ll be more productive than is realistic

And it inspired me to think of other reasons, not directly related to the team, that might cause the team to underestimate.

This is related to a recent post I wrote as a reaction to a Roman Pichler piece. It’s not that Pichler’s (or Cohn’s) pieces are bad. It’s just that they’re team-centric, with a lens directly focused on the team. And that’s fine.

But it’s not the only factor that can influence poor performance (in the Pichler case) or underestimation (in the Cohn case).

So, it inspired me to consider other factors that might influence an agile team to fall into the underestimation trap. Please consider this a “Yes, and…” to what Mike wrote.

Systems Dynamics

I consider many of these to be organizational or systems dynamics that influence estimation or underestimation. By system, I’m referring to the team or group instead of individual behaviors. They include—

1.     Overall skill level of the team – these are non-domain-specific skills. For example, the UX design experience and skill level within the team.

2.     Domain / SME experience – this is the counterpoint to the above, which is the amount of domain-specific skills within the team. I often find these skills in a single team member who often, knowingly or unknowingly, dominates the team.

3.     Dominant voices – are there dominant voices (experience, skill, personality, etc.) within the team that dominates the estimates (lower or higher)? Another aspect of this is a lack of deep democracy or listening (encouraging) to all voices on the team.

4.     Lack of big picture (big wall planning, envisioning, story-mapping) – often, estimates are off because the team hasn’t considered all aspects of delivery, let’s call that the big picture. Having that view, not only for the team but across teams, can be incredibly useful.

5.     Insufficient refinement and spikes – One of the ways to get a big picture is doing a bit of upfront analysis by prototyping, mocking something up, or other fast, low-fidelity means to better understand the problem.

6.     Hubris, wishful thinking, and optimism – one of the common areas I see in many teams a lack of realistic thinking or contingency thinking. Often, they misconstrue this with buffering or padding. It’s not that. It’s considering all of the work and is related to Cohn’s #1 and #6. That said, it’s a more holistic or systemic part of the culture.

7.     Organizational pressure or lack of psychological safety – is it safe to estimate accurately or honestly? Often, leaders want to hear what they want to hear, not the truth. Largely because the truth takes much longer than they anticipated.

Wrapping Up

The other challenge with systems-level issues is that they are often related to leadership setting the table for the team to be successful. So, it’s a system issue but also a leadership issue.

As I’ve said in previous articles, I think the best way to improve underestimation is to start by looking at and addressing the more systemic challenges before putting the entire burden on the team.

I’ve often found that the team will emerge and improve independently if you address systemic challenges. Teams are quite resilient and smart that way.

Stay agile my friends,

Bob.

Comment