Regardless of your position and company, you’re quite often requested to provide estimates for the work you need to do. Providing an accurate estimate is definitely a tough task but there are ways to improve your chances to get closer to the actual time spent to develop the work.
For time estimation, we can categorize the estimation techniques in two groups: absolute and relative. Absolute estimation is the more traditional way where you provide a quantified value according to a specific unit, for instance, 16 hours, 2 days, a week. Relative estimation turned out to be quite common too and focus on comparing the sizes of two or more tasks by abstracting the unit itself. Story points and T-shirt sizes are usual examples of relative estimation approaches. In this post, we’ll be focusing more on absolute estimates. Relative ones will be covered in a future post.
Regardless of the estimation approach you decide to follow, there are a few common mistakes you should try to avoid:
- Provide estimate without knowing the scope: Usually, people are pushed to provide estimates without understanding what they are supposed to do. If you’re estimating stories or tasks, make sure you’re able, based on the acceptance criteria and/or description, start developing that piece of work right away. If you cannot do that, ask for more explanation, discuss more with the PO or with the team.
- Be the only person weighing in on an estimate: If the estimate process takes into account the opinion exclusively of the assignee, it’s likely that few factors will not be considered in the estimate. Challenging someone’s estimate is simple and effective to make sure that different variables were analyzed when providing the ‘magical’ number.
- Be restrict to the coding effort: Developers will probably take into account only the time to write the code and build it. If you ask a QA analyst for an estimate, they will probably consider only the time to start validating and provide test results. None of them are to be blamed. They are just reacting to the environment and the kind of activities they are expected to perform. Unless you have an explicit list of expected checks/activities to be performed, usually referred as Definition of Done (DoD), your team will not have a consistent and common understanding about what’s provided when something is marked as Done.
- Be afraid of saying ‘I don’t know’: Saying ‘no’ or ‘I don’t know’ is usually seen as a sign of weakness or lack of experience. If your team is saying that, you’re blessed! Don’t judge them! Realize that’s an indication that they are being honest and that additional work may need to be done before an estimate can be provided. In those scenarios, you could 1) have more discussion to try to clarify the work or 2) create spikes (or Proof of Concept – PoC) stories/tasks to build the knowledge and reduce the risks of unrealistic estimates.
Absolute estimating
Without taking sides (absolute vs. relative), there are ways to improve your chances to come up with a realistic (or at least kind of). See below two techniques used for absolute time estimates:
- PERT (stands for Program Evaluation and Review Technique): Instead of providing one single value and stick to it, PERT requires the estimator to provide three values considering three different scenarios: pessimistic, most likely and optimistic. Those three values are included in a weighted average assuming weight = 4 for the most likely estimate. Optimistic estimates can, for instance, consider that some dependencies will be provided right away, while pessimistic ones can assume some risks will become true and will inflate the work to be done. The PERT formula is as follows: P = (O + 4*M + P) / 6. Adding one or two standard deviations can give you an extra cushion for unknowns. More details about how to calculate the standard deviation you can find here. By using PERT, you’re explicitly thinking about other scenarios and that exercise will help you to improve your estimates.
- Analogous estimation: This technique relies on estimates of past similar tasks to size a piece of work. Historical information is used and the differences between the past and current work are discussed with the team to come up with the estimate. Even though this can a useful technique, there are two aspects to keep in mind:
- Software development tasks are hard to be similar: While engineering activities (like building or painting a wall) can be quite similar from project to project, software tasks can look similar but may end up being quite different depending on the environment and the assignee.
- The time required to find a similar task: Depending on the amount of historical information, finding a similar task can lead to a waste of time. If using analogous estimation will slow down considerably your process, it’s an indication that it may not be a good fit. Remember that unconsciously everybody will end up using their previous experiences to estimate the work.
An elementary mistake is to consider effort = duration. If you estimate the effort in days and use that as the task duration, you’re unrealistically assuming 100% of allocation with no room for attending meetings, resting, reading e-mails and so on. A decent strategy (even though it requires more management work) is to consider a percentage (you could start with 75%, for instance) and tweak it for each team member depending on the average actual hours worked. That percentage will be tightly coupled with the environment and the internal processes of the company. The leaner and the more agile your company is, the higher that percentage will be.
In the next post, we’ll cover relative estimating and the different techniques to improve it.