Team Estimation by Ron Lichty

The fundamental problem with estimating is that, no matter how good our estimates are, they won't take into account all the gotchas that arise when doing actual development. So our goal needs to be: give ourselves a reasonable range that represents best and worst cases - and not spend more time estimating than the exercise is worth.

Estimating is hard, in part, because we developers tend to deep-dive into detailed analysis even though we don't know enough for most or even any of the detail to be valid.

Agile has an answer: we use relative-sizing techniques - how this task compares to a task that we already know the size of, rather than trying to "measure" tasks in isolation - and non-time units, typically abstract Fibonacci-numbered "points”. By keeping point-estimates a measure of effort (not time) and tracking points per sprint, after a few sprints we can begin to leverage the team's history to calculate velocity - and for planning purposes to apply velocity to get rough date ranges.

The most commonly used relative-sizing technique - and the one scrum trainers have traditionally taught - is Planning Poker. There are plenty of Planning Poker descriptions out there - I won’t repeat them. In part, because…

A half dozen years ago I learned another technique from Chris Sims that he learned from its originator Steve Bockman that we all think is better. Perhaps I'm just not skilled enough with planning poker, but in my experience, story sizing is both richer and faster. It’s a technique that has, for me as well as many others, yielded better results in less time with more positive, bang-for-the-buck side benefits.

Generally just called Team Estimation or Story Sizing (or occasionally Rapid Release Planning or The Team Estimation Game or Snaking), the technique is a two-step process: first the entire team orders the stories by size on a table or a wall; then, after labeling the smallest card a '1', the facilitator moves his hand along the card line until there's a card that's clearly no longer a 1 but twice that, so labels it a '2'; and so on.

I modified the method a bit and I think I improved it, but my changes are nuance to a technique this good already.

Sizing a 120-story backlog

I've worked with teams unfamiliar with agile and not comfortable with assigning "story points" or any other arbitrary value system who were nevertheless quite willing to compare each card with the next to sort them and then size based on '1' being the duration of the smallest card. (Midway through, I heard one say, "This seems like five of the first task.")

There's something very tactile about turning off all the computers and getting everyone comparing 3x5 cards on a big conference table, comparing this card to the others, asking whether longer or shorter. Things get very collaborative very fast - not only efficient sizing, but it generates team-talk as a highly productive side effect. (If your team is distributed, you'll use a tool like Miro or Mural to the same purpose!)

To my contention that Steve’s method is faster, I took a team unfamiliar with agile through planning their 120-story next-version release in less than two hours. That was both creating a snake of cards from smallest to largest on a conference table, then putting down markers for where 1, 2, 3, 5, 8 and so on started.

To my contention that Steve’s method is richer, there was discussion around every card as it came up ("Why is this card bigger than that one?"), not just where disparities might have arisen in poker "hands".  The team had previously been focused on v.1 and was not familiar with the v.2 roadmap, but by the end of two hours everyone had a sense of the entire project. I don't want to say they "knew" v.2, but I will say I've never seen anything like it for bringing an entire team up to speed fast.

One of the things that struck me, then, was how the shy-est developer in the room was soon up and negotiating difficulty, ease and complexity based on the code she knew. The teamwork and learning, in just two hours, was phenomenal.

I'm told by Scrum conference attendees that Team Estimation is getting more and more shrift these days and may be on the verge of overtaking Planning Poker as the preferred method, at least in this region.

Steve Bockman wrote a 99-cent ebook Practical Estimation: A Pocket Guide, describing his technique.

Here's a blog post by another of my colleagues, Chris Sims - how he described it.

Chris has since written a core scrum book and posted this description of the technique as he now practices it - quite a bit more structured than the original.

Steve Bockman has also written a novel, Predictability, to evangelize good estimating and burndown practices. A short and highly enjoyable read, Predictability resembles The Phoenix Project for software development. Via the narrative, it easily answers the question, "Why do we estimate in points?" It captures the crazy workarounds and multipliers we used pre-agile as a work-around to attempt sane estimates. And its chapter 12 is a compleat guide to Team Estimation.

Your biggest challenge, when you finish reading Predictability, will be realizing that its simplicity actually applies to your project. Trust me, it does. Go back and re-read chapter 12 with your team and apply it.
Or if you must, get just the guide: As I noted, Practical Estimation, is still just 99 cents on Amazon.