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.