The Case for Arguing over Estimates…

If you’ve worked on a scrum team or have some knowledge of scrum, then you are probably quite familiar with team effort estimation. “Backlog Grooming”, “Story Time”, or any other name you have for it, is the regular review and estimation (in effort points) of the product backlog. The effort points (sometimes called “Story Points”) system itself creates a common language for the development team and this recurring review forces conversations about what is coming and what it will take to get it done.  Best of all, because all work must meet the group definition of done, it requires that the team understand the effort for all parts and team members included in getting to the definition of done.

Whether I’m wearing the the scrum master or Product Owner hat, my hands-down absolute favourite moments are when there is significant disagreement on a user story. If you’re imagining people throwing laptops and hurling superlatives, I should probably note that I have had the privilege to work with teams who; a) love to learn and challenge themselves, and b) respect one another. So disagreement is less scary and more interesting and informative. On my teams, we usually start with a high-level overview of a work item (not too nitty-gritty) in order to ensure that people don’t start forming an agreement on the approach, assumptions, etc. up front. We get the 10,000ft view and then we play planning poker.

A planning poker session where, for example, both a “3” and a “13” are submitted for the same work item, usually comes from one of the following:

  1. One or more people are unaware of a component/dependency/current situation/area of overlap

Great! This means that we’ve identified a knowledge gap that might otherwise have lingered or contributed to issues

2. One or more people do not understand the effort of a department/team other than their own

Fantastic! This might be another project team or another team role on the cross-functional team. A developer might not know that this item will require a high level of new test automation from the QA department (assuming the definition of done or acceptance criteria include automation).

3. One or more people don’t have a full understanding of the work item we just reviewed

Excellent! Without this planning poker and disagreement, everyone would have assumed that they all read/heard the same thing from the user stories and specifications just discussed. By testing it out with effort estimates, we discovered what would otherwise have been missed.

4. Someone sees a better approach

Could there be a better reason to disagree?! Often this is more senior team members training up more junior members, but sometimes it’s the junior members testing out ideas, questioning assumptions or just knowing a better approach or simpler method. Regardless of the outcome, everyone learns something and gets stronger.

(Note: I strongly recommend taking actions to ensure a culture where this will not fade over time. If everyone quickly shoots down the idea, expect fewer and fewer people to speak up in the future.)

Regardless of the reason, there are a few consistent benefits of this process:

  • You and the rest of the team get a deeper knowledge of where things are at
  • Issues are made more clearly aware to the whole team (ex: dependencies will pop up far ahead of when they are impactful)
  • Everyone gets more cross-functional. Business Analysts get to know the development effort, Developers get to know the testing effort, etc.
  • Everyone gets smarter! When the strongest idea always has a voice, the average of the group is constantly improved.
  • When done well, the team builds up trust and respect, which contributes to better flow, improved velocity, and ultimately happier teammates.

As long as it’s done respectfully and in a way that protects and fosters an environment of collaborative improvement, disagreements and yes even arguments, are an essential part of team growth.

Effort estimates are a great place to improve team knowledge, communication, trust and culture. So don’t be afraid of disagreements or even (respectful) arguments — just give them a productive home that improves the team.

 

Jaeger Consulting Group specializes in end-to-end implementation for IT systems – support from analysis and design through development, deployment and training – in order to meet and exceed client goals.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s