Project Estimation - A Practical Approach
Estimating work is hard but crucial. Projects often run into unforseen challenges, designs take multiple iterations, and problem solving often involves interactions with multiple individuals. Stakeholders don't always understand the scope and challenges of tasks presented to their engineering teams, and have to rely on some form of estimation in order to prioritize work. Estimators don't always have perfect foresight on the difficulty a task. Success of business strategies often comes down to the quality of these difficult to make estimates.
Avoid Estimating Time
A naive approach to estimation may involve assigning time to particular work. For instance, a single task may be estimated to take 4 hours to complete. I've found that this approach sets unrealistic expectations and fails to account for the varying speeds and skill levels of the team. Often, to make matters worse, the time estimate becomes a constraint, forcing compromises to be made by both engineers and stakeholders in an effort to stay on track.
Time is a bad measure for estimating work because its likely that team members will disagree on how long a task will take, even if each members estimate accurately predicts how much time they will need to complete the task. This unfairly highlights the skill gap between team members, and leads to inflexibility when assigning tasks.
Not all tasks can have an obvious time to complete. Tasks that require involvement with other groups (especially with asynchronous communication), or that require research and experimentation will not be easy to estimate with accuracy. Poor definition often leads to back-and-forth between engineers and stakeholders or mistakes in implementation that make tasks take longer to complete than anticipated.
Ideal Estimating Measure
An ideal estimating measure would be one that is likely to be consistent across all team members, and accounts to uncertainty that comes from various sources. The estimate is made by the team in order to describe the effort, resources, and risk a task is likely to consume. Stakeholders can use this estimate to compare tasks (or tasks in potential) on the organizations roadmap, and prioritize.
A comparative measure is much easier to determine, and is often all that is needed to prioritize work. Estimating the difficult of a task relative to a simliar task is much easier for engineers to do accurately.
Story Points
The "Story Point" is a measure often used in Agile teams to describe the cost of a task, rather than hours. A team will decide to assign a number of story points to a task, which is a unitless measure of effort or cost. These story points are used by managers or stakeholders to prioritize the next sprint.
One strategy for choosing point numbers to assign is to only use numbers in the Fibonacci sequence. This helps eliminate minor inconsistencies between team members. Large tasks are more difficult to estimate, so the Fibonacci sequence naturally creates distinct gaps between sizes, making comparisons of large tasks fuzzier. This is a good thing, because a large tasks is also more difficult to estimate.
Task Sizes
Sizing tasks takes the Fibonacci strategy even further, by attaching a description that helps all involved parties understand the rationale behind any estimate. While the exact reasoning behind a single estimate might be slightly different than others, they all take into account the following criteria:
- Clarity of the description
- Complexity and the tendency to grow
- Certainty of all factors involved
- Subjectivity of the acceptance criteria and ability to test
- Time relative to other tasks
- Familiarity of the work to the team
- Difficulty of the work
- Involvement of other parties
The sizes and their corresponding story points on the Fibonacci sequence are shown in the table below.
| Story Points | Size | Description |
|---|---|---|
| 1 | Trivial | simple enough to be completed in short time and can be easily verified |
| 2 | Extra Small | well understood requirements, but may make some small assumptions that need to be checked |
| 3 | Small | likely simple, but has the possibility ot taking a little extra effort to finish or test |
| 5 | Medium | can be completed with effort, but not likely to involve interaction or major difficulties |
| 8 | Large | carries considerable uncertainty, difficulty, or potential to require multiple development sessions |
| 13 | Extra Large | likely to take multiple sessions to complete or involve much interaction with other parties |
| 21 | Heavy | would take significant effort and time, may involve much investigation, subjective measurement, or trial-and-error |
| >21 | Too Big! | We are unable to do the work as it is written. The task is too complex, involves too many unknown variables, or is not able to be completed in the time-frame of a single sprint. |
While not every task will fit a description exactly, estimators can find the closest description that fits and choose to go up or down a size considering the factors mentioned above.
Tasks that are too big should be rewritten into smaller discrete tasks.
Closing Remarks
I've arrived at a system like this for my work, after struggling with the problems that come along with estimating. Both stakeholders and engineers have embraced the system, as it has improved the quality and usefulness of estimates. As with any system, your mileage may vary if you try this for your own team.