Running an estimation workshop
Exploring different Agile estimation techniques with our team in Taipei
I came across this workshop online while browsing through the trove of excellent Agile resources on the GrowingAgile website.
The workshop, and Karen’s reason for running it, sounded painfully similar to what we were sometimes experiencing in our team. We too were running Planning Poker® and sometimes team members were getting too caught up in the actual number, and what it meant. Some were also falling into the habit of “defending” their own estimates with the goal of being “right”.
As Karen so eloquently put it:
“I like to remind people that what we care about is getting a shared understanding and consensus, not necessarily worrying too much about the actual number.”
This exercise seemed like a great way to introduce the concepts of Agile estimation, with a variety of techniques to learn from. I decided to run the exact same 4 exercises with my team so that I could compare outcomes and notes.
As we only have 10 development team members in our Taipei office, we split into 2 groups.
🐶 Absolute estimates
The goal here was for the groups to guess the average weight of dog breeds as accurately as possible.
Like with Karen’s teams, this method was the quickest technique of the four. Our groups agreed that it was easy to guess knowing that they had almost zero idea so were completely comfortable with being wrong. The language barrier and knowledge of breeds also played a part here. The inclusion of the made up Appalachian Mountain Dog breed resulted in the outcome with our teams.
🌍 Planning Poker
As mentioned, our team currently uses the Planning Poker technique when estimating our backlog items. We use an online Planning Poker solution to cater for remote team members. The goal here was to use this technique to estimate the area of countries. Again, we used the same data and reference point of Spain as 3 points.
This method turned out to be our slowest even though it was the method we were most used to. Team 2 finished considerably quicker than Team 1. From our discussion, the delay was caused because Team 1 could not reach consensus. They realised that they spent most of the time trying to prove their own guess correct, without trying to gain consensus. What also helped Team 2 was a team member who knew the general sizes of countries like Luxembourg, Denmark and Belize.
🚗 Affinity estimation
I was first introduced to this technique by a blog post on Chris Sterling’s website GettingAgile. I had never run this technique before and I found Karen’s summary quite useful in keeping my explanation of this technique short and to the point. I also thought to follow her example and have teams stick to silence during the exercise, discussing items only when a card had been moved by everyone. The goal in this exercise was to estimate the size of vehicles.
This method went a lot quicker than our Planning Poker session. I felt this may have been due to the team feeling more at ease with the casual nature of the exercises. Once again, the team insights mirrored those of Karen’s teams — some members enjoyed that they felt less influenced by others.
🐘 Relative estimation
My first ever introduction to Story Points and Agile estimation was using a form of relative estimation and t-shirt sizes to compare task effort. Karen’s technique is really transparent and easy to understand (and explain) so I would highly recommend it. The goal here was to estimate the size of animals.
This technique was marginally slower than the absolute estimation technique. The teams found it relatively easy to decide which animals were larger or smaller than others. There was disagreement with how much larger or smaller once the points were introduced. The disparity between the teams in the scores above could have been avoided had I given a clearer definition of “size” here. Team 1 used height as size, where Team 2 used “volume”.
🌯 Wrap up
After we’d completed all exercise, I asked the teams what they had had noticed. The first point highlighted was that it seemed a lot easier to feel confident in estimating when we had a point of reference. Another point brought up was that it helped when at least one member of the team had some knowledge of the subject matter.
Finally, I asked how if we could use any of this knowledge in our Sprints? The unanimous decision was to continue with Planning Poker with the addition of reference tasks.*
This workshop is a great way to introduce your team members to different techniques of estimating tasks when not all information is known beforehand. While certain techniques do seem to produce more consistent results, the main goal of this is not the accuracy of the estimate, but the consensus reached by the whole team.
*We have since run a follow exercise where the team chose their own reference tasks — in a future post I will discuss how we did this, and what the effect on the team has been.
