Somehow, everyone learned about planning poker. You know, the game where everyone gets a set of cards with different point values on them (usually in a Fibonacci sequence). Then they vote about the size of a story by holding up their cards simultaneously and work to reach consensus.
That’s a fun way to do estimation in a group, and it is appropriate in many situations. But what if you need to estimate 30 or more stories at a time? What if you just held a story brainstorming session and you’d like to get high-level estimates for ALL of the stories you just came up with? In this situation you don’t want to dig into stories one at a time, and get bogged down with discussions of acceptance criteria for each one.
Affinity Estimation
In this type of situation, I favor a technique knows as “affinity estimation.” This technique has been around for quite a while, and I always teach it when I’m doing any kind of agile training. So it’s surprising to me that not more people know how to do it.
In affinity estimation, you utilize people’s natural ability to compare things against each other. Rather than dealing with individual stories, you estimate a set of stories in the aggregate.
The technique is fairly straightforward. Here is how I practice it.
- Write each user story on its own index card (if you don’t already have cards for the stories)
- Place all of the story cards on a table facing in one direction, and have the estimators stand on the side of the table facing the cards.
- Ask the team to arrange the cards based on their relative level of effort to implement. Have them put the smallest (easiest) stories on the left and the largest (hardest) stories on the right. Some teams like to do this part silently—with no verbal communication allowed.
- Once the team is satisfied that the stories are in a good order, ask them to partition the stories into 3-5 “buckets” where stories in each bucket are roughly the same amount of work. You can separate the buckets with tape if desired.
- Place a header card at the top of each bucket, and label each bucket using a T-Shirt size (e.g., S, M, L, XS, XL).
- After labeling the buckets, have the team do one more pass until they are happy with which bucket each story is in.
- Develop a linear/relative scale for the different bucket sizes as follows
- Write “1 Point” on the smallest bucket
- Compare the stories in the second smallest bucket with those in the smallest bucket and determine a relative level of effort (e.g., they are, on average twice as much work)
- Write a point number on the second smallest bucket
- Proceed up the buckets, writing a point value for each which best expresses the relative size of the stories in that bucket to the stories in the previous bucket
- Write the size/point values from the bucket label on each of the story cards in the bucket.
Using this technique, you can estimate 50-100 stories in easily under an hour—usually in under half an hour.
And these estimates are good enough!
A True Story
I once coached a team doing release planning on a large government project. Both the team and the program were new to an agile style of development.
After we had created a set of stories representing all of the things we might build in the release, I led the team through an affinity estimation exercise (as described above), which took approximately half an hour. This gave us a set of estimates that we then started using for our planning, and for committing to how much could be accomplished in the release.
Coming from a more process-heavy approach, the vendor team was very uncomfortable with these estimates. They requested the ability to go back through the set of stories and re-estimate then using their traditional approach. Since we had some extra time in the release planning schedule, I agreed to this.
For each story they broke it down into technical tasks, then estimated hours against those tasks and applied their historical load factors to figure out how much could be done by the release date. They often spent up to half an hour or more on each story, speculating about detailed requirements, etc. This process took roughly a week’s worth of meetings.
At the end of the process, the team’s revised estimate of what could be done in the release timeframe matched EXACTLY what we had come up with using the affinity estimates. There were many variations in individual stories, of course, but in aggregate the answer was the same.
The team realized this and was taken aback. They started to believe in the law of diminishing returns for estimate—the 80/20 rule that gives you 80% of the value with only 20% of the effort.
Parting Thoughts
Everyone benefits when teams and organizations learn how to do affinity estimation. The ability to quickly get a high-level set of estimates for a set of stories is useful in a variety of situations. Use it in a release planning workshop, for looking ahead at the next 3-6 months’ of work. Use it when a brand-new feature comes at you out of the blue. Or use it to put together a bid for a new project when the proposal is due tomorrow!
Most importantly, use it in place of “Sorry, we haven’t estimated that yet.”
Pingback: Maria Smith()