Task Estimation

Avi Siegel

•

9 min read

What is task estimation?

Task estimation is a process used on Agile teams where engineers agree upon the amount of work each task represents. It is officially performed during the Backlog Grooming ceremony (although it sometimes bleeds into Sprint Planning as well). The process helps the product manager (PM) and engineering manager (EM) plan sprints, understand when blockers may be impacting progress, and provide a view into the team’s velocity over time.

What are the goals of task estimation?

The primary goals of task estimation are to:

  • Finalize the preparation of backlog items so they are ready to be pulled into a sprint

  • Enable the PM to prioritize more effectively (e.g., it may be worth resolving a bug if it’s expected to take one day, but it may not be worth resolving it if it could take two sprints)

  • Nudge the team to further break down large sets of work when feasible

  • Inform the team as to approximately how much work can be done within an individual sprint, so it can be filled accordingly

  • Enable the PM and EM to know when it may be worthwhile to consult task owners about tasks that are moving slower than expected, so they can remove blockers and provide additional resources as necessary

  • Give the PM and EM and higher level leadership insight into team velocity so they can understand how far out the completion of certain sets of work may be

Pro Tip: Do not allow a purpose of task estimation to be to call out engineers for taking too long on a task. When work takes too long, the learning (e.g., during a Retrospective) should be that the work wasn’t well understood, and to improve that understanding the next time around. If the result is that engineers get reprimanded when work doesn’t go according to plan, there will be a lot of push back with estimation (and/or, tasks will be far overestimated so as to avoid potential negative repercussions).

What strategies are used to estimate tasks?

At its core, the process of task estimation means that teams need to apply a specific value to an impossible-to-know-perfectly set of work. This mismatch of “exact” and “inexact” necessitates the use of strategies to make this imperfect process practical, effective, and useful.

Encourage abstraction of estimates

Estimates are determined using a combination of:

  • Expected effort - how much work does the task entail?

  • Uncertainty - how confident is the team in the estimate?

An important detail here is that expected effort is an abstract representation of the size of the task - it is explicitly and purposefully not a reference to the amount of time the task might take. This is by design, because:

  • It is essentially impossible to know exactly how much time a given task will take

  • The amount of time a task might take will be different for each person who might pick up the work

Even for teams that understand this necessary level of abstraction, it is admittedly difficult for individuals to think about estimates completely abstractly. And so, it is common for teams to reference time in their deliberations, but importantly, with specific anchors in place. For example, a 1 point task may be expected to take a senior engineer up to 1 day to complete, but a junior engineer may take longer, and a principal engineer may take less time. In this way, “1 point” would not represent “up to 1 day”, but rather would represent “up to 1 day for a senior engineer”.

Select an estimation scale

The most common estimation scales employ the Fibonacci sequence and T-shirt sizes:

  • Fibonacci sequence: 1, 2, 3, 5, 8, 13, etc. For instance, a 1 may represent “up to 1 day for a senior engineer”, whereas a 5 may represent “1-2 weeks for a senior engineer”. In such a setup, 5s should be rare, and anything higher than a 5 should be broken down into smaller tasks.

  • T-shirt sizes: S, M, L, XL, etc. For instance, a Small task may be expected to take “up to 2 days for a senior engineer”, whereas a Large task may be expected to take “1-2 weeks for a senior engineer”. In such a setup, Ls should be rare, and anything higher than an L should be broken down into smaller tasks.

A note on other scales: Some teams select other options for their estimation scale of choice, such as powers of 2, a strictly linear sequence (1, 2, 3, 4, etc.), or others. These tend to not work as well as the above options - for example:

  • Powers of 2 may sound like a logical choice for engineers, but most find it does not provide enough discrepancy as the numbers get higher (which occurs quickly due to the exponential nature of the scale).

  • Linear may sound logical as well, but most find it also becomes less useful as higher numbers are reached, in particular because people tend (even if they try to avoid it) to think about estimates in terms of days. E.g., how confident can a team really be that it will take a senior engineer 4 days vs. 5 days or 9 days vs. 10 days to complete a given task?

Pro Tip: With rare exception, all tasks should be completable within a single sprint, and thus estimates should not exceed the value that is equivalent to a full sprint based on your team’s estimation strategy of choice. You can still apply such large estimates, but those tasks should almost always be broken down further.
Pro Tip: Create an estimation matrix to formally document what each value on the estimation scale means to the team. This will ensure that there is no confusion as to when each value should be assigned - and that way, the team can spend more time debating effort and uncertainty than the purposefully-abstract value estimate itself.

What is involved in task estimation?

Task estimation is performed during the Backlog Grooming ceremony, as each task is discussed. The final result of this part of Backlog Grooming is that each task will be assigned an estimate as to how much work it represents.

By far the most common approach to estimating tasks as a group is an exercise called “pointing poker”, where the team votes on task sizes. When employing this exercise, the below activities will be performed as a team for each task.

Review, refine, & understand task

The PM will present each task, after which the entire team will discuss all relevant details about each task, including (but not limited to):

  • Context

  • Job stories

  • Core requirements

  • Acceptance criteria

  • Available visuals (screenshots, mocks, etc.)

  • Outstanding questions

Refine the task as necessary. This may entail further editing of the details in the task, or if it is too large, breaking down the task into smaller tasks.

Note that this part of the exercise is more specific to the Backlog Grooming ceremony than the task estimation part of Backlog Grooming, but it is an important precursor because it leads directly to the explicit understanding of the work described by the task. With that understanding, the team can move on to estimation.

Vote on task estimate

The EM will open up voting so that each team member can provide their estimate. This can take the form of:

  • A tool that allows everyone to vote, and after all votes are in, allows the EM to reveal the tallies

  • Timed raising of hands, with the number of extended fingers denoting the size

  • Open discussion where someone with the most context provides their estimate, and discussion amongst the team ensues

Pro Tip: Encourage individuals to not shout out their answers immediately. Even if they feel they are intimately familiar with the work a given task entails, this behavior will unduly influence the task estimation process if someone tells everyone else how they’re going to vote before the voting is completed.
Pro Tip: Consider utilizing a tool to help collect estimates. This will help formalize the process, and also will help make the timing of vote reveals be exact, so that individuals’ votes can not be unduly influenced by seeing other votes before committing to their own.

Discuss & agree upon task estimate

Once the votes are in, it will be clear as to whether there is broad agreement or disagreement on the size of the ask.

If there is agreement, the agreed-upon size can be assigned to the task.

If there is disagreement, the EM should open the floor for discussion. It is often easiest and most useful to start with someone who disagreed with the majority opinion, as the difference in votes reveal they might know something the rest of the team does not. For example, if 4 engineers voted for a 2, and 1 engineer voted for a 3, perhaps that engineer is aware of an aspect of the work that may prove to be more difficult than others give it credit for. Or, as another example, if 3 engineers voted for a 3, and 2 engineers voted for a 1, perhaps the engineers with the lower votes have done this exact task before, and know it is heavily documented and straightforward to complete.

Pro Tip: Round up. It is all but impossible to know exactly how much time a given task will take. Uncertainty should already be factored in, but even then it may feel like the “right” answer is, say, somewhere between a 2 and a 3. Always err on the side of giving the team more time. It is better to deliver early than mismanage expectations and have timelines slip.

Once the team is in agreement as to how much work the task entails, the EM will assign the estimate to the task.

Who participates in task estimation?

Task estimation is performed during Backlog Grooming, which means that the same individuals will be present as during that ceremony:

  • Product manager (to present tasks)

  • Engineering manager (to lead the voting process)

  • Engineering team (to collaborate on the sizing of each task)

Pro Tip: The PM may have an opinion as to the size of the task, but they should not make that opinion known. It can be easy, especially as they are the one speaking immediately before task estimates since they are responsible for presenting the tasks, to transition directly to their own thoughts on sizing. However, the PM is often out of their technical depth, and will unduly step on toes and influence the estimation process if they are too forward with their beliefs.

Best practices for task estimation

  • Estimate tasks in real-time, together as a team. It can be enticing to attempt to perform task estimation asynchronously to save time, but without discussion it is unlikely to result in accurate estimates. When there is disagreement on the estimate (as there typically is), conversation is necessary anyway, and often more efficient live. And even when everyone agrees upon an estimate, it is possible that discussion would have revealed unknowns that would have increased the estimate or knowns that would have decreased the estimate.

  • Don’t feel the need to debate estimates until no dissenters remain. Task estimation is not about being exact, it’s about providing reasonable-effort best guesses. Be cognizant of the time you’re spending. For instance, if after 5 minutes of discussion, a single engineer still thinks the task is a 2, but everyone else believes it should be a 3, the EM should close out the conversation, and make a final call one way or the other. In cases where the one dissenter is both the person with the most context and the likely person to be assigned the task, feel free to go with that person’s gut - allow them to own it.

  • Utilize the task estimation process to encourage the team to break down work more than they might otherwise be inclined to. The higher the estimate, the more likely it is to be wrong - the more work involved in a task, the more pieces of the system it may touch, and thus the more unknown-beforehand complications may arise. That means that small estimates are pure gold - the team more confidently believes the work will be done quickly. As such, expectations can be better managed when there are more smaller tasks than larger ones.

  • Get ahead of objections to task estimation. The biggest objections engineers often pose to estimating tasks is that 1) it’s impossible to know how long something will take (so why bother), and 2) they don’t want poor estimates to come back to hurt them later (in the form of being reprimanded for work taking longer than they said they expected it to take). To get past these objections, both leadership and the engineers need to understand and agree upon the purpose of estimation. On leadership’s side, there needs to be no negative repercussions for “bad” estimates. On the engineers’ side, they need to recognize that it is impossible to plan with no estimation. If the potential negatives are removed from the equation, the positives can stand out and be achieved.