I’ve been doing Parkrun for a year now. Yes I’m one of those crazy people that get up early ever saturday morning and run 5 Kms with 300 other Parkrunners. After awhile, something interesting happened, I was asked to explain estimation to a group of people new to agile ways of working and found that I could explain relative estimation by using my Parkrun experience with my friends.
The requirement is the same – run a distance of 5 kms. However, the duration of time will vary widely between runners. Even though the Parkrun is a set 5 kms, it takes our whole group to finish anywhere between 20 – 55 mins.
So why don’t we all finish at the same time? Well, there are a number of factors to consider including our fitness, age, equipment and expertise at running as well as the complexity of the course (each Parkrun differs in elevation and intensity) and if we are going for a PB or recovering from injury.
Let’s look at my running friends as a typical team, our range of times are different for the same course:
- Jamil is incredibly fit and runs marathon and can run 5 kms in 18-20 mins
- Hua, Bob, Najia and Zanine are good regular runners and often finish at around 26-28 mins
- Mandy and Jude finish in around 33-35 mins
- Me, I’m getting times between 35- 37 mins
- Simon is recovering from injury and takes 40-45 mins
- Peter prefers to walk and takes 55-60 mins
So if we were to ask Jamil to estimate what it takes to run 5 kms, he will estimate 20 mins. But he is the only one in our group that could do it in that time. The requirement for all is the same but the complexity, uncertainty and effort (CUE) is different depending on a number of external factors as well as individual factors such as age, skills and expertise.
Relative Estimation is a range
A 5 km Parkrun on a Saturday morning can take between 18-60 mins for us all to finish. This is a big range. So we “self grade” at the start to line up and group ourselves into the section of runners that fits our likely estimated finish time. We all have garmin/starva type apps that give us metrics and data on our pace/km, length of course, total time to complete, average weighted time (based on age and ability), elevation and so forth. Over time we have enough data to make some more predicable estimates of our likely finishing time for the whole group.
We use relative estimation based on our past pace stats to line up. I would line up closer to Jude as her pace is about the same cycle time as mine. If I run with Kirsten, she will push me, my pace will be higher and I’ll likely finish with a better time. However Kirsten’s time when she paces with me would likely be slower as she adjusts to pair with me (as I couldn’t sustain her usual pace for the whole 5 kms) and so Kirsten’s time when running with me would be slower. Context is everything.
If we invited a new friend join us, we would use relative estimation to guide them to estimate/line up at the start, based on their experience, fitness, type of course, first timer status and so forth.
Relative estimations help with Predictability
The same is true with estimations for work products (software and non-software). There is natural variability between estimates by people. Accuracy of estimates are often guesses in the beginning and are widely inaccurate. This is because people are optimistic of what can be done in a timeframe or the estimate is done by experts and not by the team who will actually do the work.
Estimates aren’t just about scoping out the work and estimating the tasks in hours to do the work and adding up those hours. Estimations need to take into account team capability, duration, size, complexity, knowledge and uncertainty.
So we use relative estimation (usually T-shirt sizes or story points) to categorise ourselves. These discrete size categories such as Small, Medium or Large are exponentially increasing and takes into account the amount of effort to get the work done as a team. Over time we can aggregate our cycle time metrics at retrospectives. This help give the team more accurate estimates and drastically reduces planning time.
