Task Estimation

An integral part of your iteration is accurately estimating the amount of time or effort a task will take to complete. I jokingly use the term "accurately estimating" as an oxymoron because every developer knows time estimates are always wrong –often significantly so. As sobering of reality as it is, it's still important to try. Not for the misused reasons to estimate tasks (such as artificial deadlines and burn-down predictions), but for coordinating the development, realistically setting the pace, and catching bottlenecks that may block your team's efforts.

In short, task estimation should be a helpful tool used by your engineers for your engineers. As I'll discuss later, you use task estimates to understand the velocity of individual engineers and the team as a whole so you can predict how much work should be allocated to the iteration.

Estimation unit of measurements

There are several estimation strategies that you could employ, and there are great resources regarding the pros/cons of each one. I will mention a few that are most common and explain why one rises to the surface (in my opinion). If you want to skip straight to my recommendation, see Dev Days.

Story Points

Story points are the most widely used form, as that's what Scrum uses and it's what is generally recommended by the Agile community. A story point is a completely arbitrary number–usually between 1 and 8–that indicates the amount of effort it takes to complete a task, where effort is determined by comparing one task to another task that already has a point value. For example, if sweeping the floor was a 3, then mopping it is probably also a 3 since they are roughly equivalent. Cooking dinner for your ten guests coming over would be a 6. Whereas if you just ordered pizza, it'd be a 1.

Story points should be roughly linear...these numbers are vague, fuzzy, imprecise things that do not relate directly to real-time. Robert Martin (Uncle Bob). Clean Agile.

Story points are beautiful simplifications because they aren't tied to time. They aren't tied to anything. They are completely arbitrary. And that's precisely why I don't use them. People are really bad estimators, true, but we're really REALLY bad at estimating without considering time. Let me illustrate with my example above. Suppose you had the same example tasks, and it was your job to as accurately as possible estimate their point values:

• Sweep the floor

• Mop the floor

• Cooking dinner for 11+

• Ordering pizza

How would you do it? Well, you'd probably start by reasoning out, "well, sweeping the floor usually takes me about 30 minutes, and I can make up some pasta and salad in maybe an hour...". You can't help but think of it in a measurement of time. It is how we measure previous experience against future effort.

Shirt Sizes

Shirt sizes is assigning general size comparisons (small, medium, large, etc.) to tasks. This has the same problem as story points and is just another form of a story point but without the numbers. Numbers are much easier to type and measure, so I don't think there is much value in shirt sizes.

Exact time estimate

The issue with story points is that we inevitably use time as our ruler. So why not just state how many hours or days we think the task will take to complete? For one, not all engineers have the same pace. Some are faster developers. Some are more familiar with the task than others. Some have other priorities that take up their day. If Susan is assigned the task, and you estimate it will take her 10 hours to complete it. What if the task is reassigned to Bob? Does your estimate change?

Additionally, although it hasn't been explained yet, we're going to lose out on all the benefits of measuring velocity if everyone on your team has roughly equal days/hours of estimated work in a week. It's also a great way for team members to compete to complete tasks as fast as possible, "well, I could complete the task in 3 hours, but knowing Karen, it's going to take her 8."

Dev Days

My recommendation is to float somewhere between a story point and an exact time estimate. Rather than picking an arbitrary level of effort for your point values, pick an arbitrary developer for your time estimates. Rather than asking how long it will take the assigned owner of the task to complete it, ask how long it would take an average, mid-level engineer to complete it.

Who is this engineer? No one. Just envision a hypothetical someone close to the average experience level of your team—someone who would be comfortable completing the task without much handholding. Then, stick to a single point-value system by using days (instead of hours or weeks). What is a day? It's the amount of work this hypothetical engineer typically accomplishes in one day with an average number of other day-to-day priorities. In other words, if this was the one iteration task the engineer worked on today, and if the task was worth 1 dev day of work, this engineer would have it done by roughly the end of the day.

For the actual point values, I recommend numbers 1 through 4. For anything under a day, I just call that a "quick fix" and use common sense to figure out how it fits within an iteration. For anything over four dev days, the task is too large and needs to be broken down.

Estimating a task

There are many strategies for estimating how many story points (dev days, shirt sizes, whatever) a task should be given. You could have everyone vote, then average the vote, but the average of many unconfident voices does not lead to a confident average. You could have a single owner –the most senior engineer– provide the estimates, but that's equally as bad. You could do planning poker, but it's a bit challenging if you're remote and it tends to consume a lot of time.

My recommendation is to do what is natural. Ask the team how long they think it'll take. If someone has a confident estimate, they will typically speak up. Those that aren't fully paying attention or aren't confident (likely due to their distance from the task) can defer. At the very least, the owner of the task should have the final say in its estimate.