Waste and group estimations

In my post on ditching planning poker, I talked about the waste we uncovered with group estimations. In fact, we found the entire sprint planning meeting to be a large waste of time. In our spring planning meetings, our entire Whole Team convened to agree on the sprint deliverables, every week. The attendees included:

  • Developers
  • Analysts
  • Product owners
  • Stakeholders
  • Testers

In all, over 20 people. Everyone who participated in the entire story flow gathered together to review the stories, do planning poker, and agree on which stories would be in the sprint.

These meeting were excruciatingly dull for everyone involved.

Imagine, 20 people in a circle, who could at any time ask any question about any feature and any number.

So, we eventually split this into two meetings, developers/analysts/testers in one to do estimation and design review, and another meeting to approve the features to be developed.

These new meetings were excruciatingly dull for everyone involved.

We estimated stories and tasks in points, so that we would complete about 5-8 stories per sprint, with tasks estimated in points. We estimated tasks to get more accurate estimates, and to have a better idea on exactly how much functionality in terms of complexity we delivered. Over the course of about 18 months, we were able to increase our velocity from around 150 points/week to close to 400/week.

Since we placed points on tasks, you can imagine how silly it is to argue about 5 points versus 18 points, when it’s such a small fraction of the whole. Everything came out in the wash, and we found the whole group estimation process to only really serve the purpose of stroking egos and producing pointless arguments.

Group estimating stories

When we estimated merely stories, and not adding up tasks, group estimation was still a waste. Developers, sitting around a table, arguing about how complex/large something is, when they could just be…actually delivering value. Instead, our team lead/tech lead/principal consultant estimates the stories in hours, validating effort at the end of the process.

When we looked at the cost of everyone sitting around, the only value we saw was in discussing the design of the story. But that was happening anyway when developers paired on a story, through whiteboarding, pair programming, or group discussions. Did everyone need to be involved? The finger tapping and bored looks of other developers said “no”.

Instead, we went to a model of huddling on stories pulled and the developers actually building the story, with the tech lead leading the discussion on what the story entailed. For particularly tough, complex or “deep” domain-rich stories, we would call the team together. But only to discuss interesting highlights, not to engage in point battles of will.

It took a little bit to build trust between the principal and the dev team to buy in to the estimations given, but developers always had a conduit to submit feedback on estimations if something seemed off. But the idea that we had to talk about every estimation was just not necessary. So we saw it as the waste it was and ditched it over two years ago, and none of our projects since have needed or used any sort of group estimation techniques. There are cheaper ways to mitigate risks than group scrum therapy sessions.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    First, it’s cool that you guys found something that works. No arguing what works.

    I do have a couple questions.

    Were there maybe just too many people at the meetings and on the team to begin with?

    What are your estimation units today, still using time?

    When you compare against actuals, is there a standard deviation you’ve identified? What do you do with that information?

    • Anonymous

      There were definitely too many people at the big meeting. At the dev planning meeting, when we did just a dev team estimation, we had 4-5 developers, tech lead, and principal (all developers). I was still bored out of my gourd :)

      Today, we’ll estimate in time units – days/hours, plus assigning variable risk factors in percentages.

      In terms of actuals, it really, really depends on the client and contract. Sometimes it matters, sometimes it doesn’t. Estimates in consulting are about setting expectations, so we want to make sure that it’s more in terms of a client knowing how much something is *likely* to cost, and not surprising them in a bad way.

      If we’re under, everyone’s happy, if we’re over, we’ll examine what was off.

      I should note that I have had good experiences with group estimations in IT and product groups, but I’m so far removed from those times that I’m not sure what a different approach would have looked like.

  • Really very interesting discuss about domain rich stories.. I think those grouph estimation techniques is very useful..

  • Excellent information and I am grateful to you for sharing such an information that I was searching for.

  • Craig Brown

    Great story. Thank you for sharing.

    We had similar issues. Our response was smaller (fully staffed) teams and time boxing. It improved things but there was still a way to go.

    Eventually I took a look at the numbers; a years worth of estimates and discovered the magic number.

    I’ve left the team now, but if I were there we’d be working off that average number if stories completed as our guide, and that planning & breakdown would be happening as the story kicks off.