General Techniques
Experience has taught me a number of best practices in making estimates for the development of software. Pick and choose among these to find the ones that make the most sense for your use cases. But don’t, as I previously warned, fall into the Waterfall Trap and attempt to perfect every estimate before you begin work. Instead, aim for reasonable estimates so that you can usefully approximate the amount of work required, then focus your time on actually getting the work done. If necessary, you can refine your estimates as you proceed.
People
- Estimation is a skill. People who have taken the time to hone this skill can both estimate better and pass along their knowledge. So try to work with (or hire) people skilled in the practice of estimation. They will help you figure out how to do it properly, resolving challenges and handling edge cases.
- With technical work it is often useful to have domain and technical experts evaluate specific areas of concern. These may be engineers from related product teams or outside experts. Don’t expect them to offer a concrete date as their estimate (and don’t trust it if they do), but they should give you more insight into the scale and any risks/unknowns that you should note.
- Estimates involving general software concerns, including scalability, quality, security, accessibility, etc., will require some level of experience to assess, but only require a true expert in exceptional cases. Good engineers can often help flesh out any estimate.
- Consider evaluating a number of different opinions on the specific and general requirements of a project to ensure that you have accounted for any concerns and constraints. Scrum teams often do this when they discuss differences in point values between team members, but this can also be useful for larger estimates.
- But limit the number of people involved and the time spent on your estimates to reasonable numbers, or you will find yourself slipping down the slope to the Waterfall.
Process
- Create useful rubrics or standards to ensure that you cover the key elements and that you have consistency in your estimates. (See my example below.) Use these to keep people aligned with your estimation process and output, but don’t let it constrain your thinking—modify it as appropriate to ensure that it meets your needs.
- Make estimates without regard to any proposed deadline, i.e., don’t fool or anchor yourself. Do the process right. Afterwards you can try to figure out approaches you can take to meet the desired date.
- A particularly useful technique is to decompose a large amount of work down to smaller pieces and estimate those. It is often far easier to understand and identify issues in smaller chunks and produce better estimates as a result. This has the added benefit that it forces you to consider working on the solution in pieces, possibly in parallel, to speed up the delivery date. Breaking things apart can add complexity, so be careful that you don’t miss pieces or oversimplify the complicated relationships between pieces.
- Identify risks and unknowns so that they can be noted and addressed. Address the issues using research, prototypes, and spikes if possible and make sure you get appropriate clarity! You can compensate for unknowns in an estimate by adding time, but it is better to resolve unknowns when possible. Clearly state all unknowns, risks, and challenges in your final report. All estimates have context surrounding them and it should be made explicit.
- As previously stated, ensure that you have reached alignment on what will constitute the expected delivery. Estimating the time to achieve the wrong goal can lead to significant wasted time.
- Leverage previous estimates that have played out when making new ones. For example, if your team creates integrations, you should be able to compare and contrast new work with previous examples to quickly arrive at a good range of necessary effort. Be honest about similarities and differences. Don’t assume that the second time will be identical to the first unless your research shows that.
- Refine your estimates by reviewing them. If you have the time, then wait and come back later with a fresh eye to see what you have missed or want to change.
- Favor time ranges in your estimates rather than precise but inaccurate values. I have used information contained in the book How to Measure Anything to train teams on the use of this technique. Common examples of using ranges when estimating software projects are the use of Fibonacci numbers when story pointing and T-Shirt Sizing (see the next section).
- Review estimation practices and examples to improve your skills before beginning. Like any skill, your ability to estimate will get better with conscientious practice.
Example: T-Shirt Sizing
It’s called T-Shirt Sizing because you are trying to break work down into a few general categories, much like t-shirts are categorized as small, medium, large, and extra large. This estimation procedure is explicitly intended to be loose and quick. The estimates are used to get a general feel for how big the project is, not to understand exactly everything that is involved.
Stick to the purpose of the exercise and don’t spend an unreasonable amount of effort perfecting your estimates. Your estimates will not be perfect, but they should be useful.
The following are notes I have used to guide T-Shirt Sizing at various companies. You will see immediately that I use ranges of effort rather than precise values. Then I explain my methodology and assumptions so that anyone looking at the estimates will have an idea as to how and why I created them.
Sizing Chart
| Effort |
| S (< 2 weeks/1 dedicated engineer) |
| M (< 4 weeks) |
| L (< 10 weeks) |
| XL (< 20 weeks) |
Assumptions
For these estimates, I assume 1 engineer who has reasonable knowledge of our code/systems and is focused on this one single project. An expert would likely do a bit better, a newbie would do worse, and multiple engineers could accelerate the work to some extent. But you have to base the estimates off of something, so I use one onboarded engineer as the baseline.
The estimates included all engineering and QA work to get the code (whatever it is) to a release-ready state. But I assume that the work is well and clearly defined, so PM and design work is not included.
To get my guesstimate, I try to think reasonably comprehensively about the order of magnitude and overall complexity of the work and generally compare that to work that the teams have already delivered (that’s what a t-shirt size is).
Two weeks is the smallest size, because anything significantly less than that and you have to wonder why it is being T-Shirt-Sized (estimated). Twenty weeks is the largest because you are contemplating four man-months of work, and it is hard to estimate a project that large. At that scale you should probably be breaking the work down into subprojects and estimating those.
Conclusion
Estimation is difficult and imprecise. If you work with the right people and use intelligent processes you can produce estimates that are wrong, but still useful!
If you rush your estimates, don’t leverage available resources, and fail to account for risks, assumptions, and the need to define clear end results, your estimates may well be useless.
But beware the Waterfall Trap, which compels you to spend large amounts of effort attempting to devise a perfect plan. If you go down this path, you are not actually estimating.
PS: The restaurant in Vanuatu I mentioned in the previous post, and shown in the image accompanying this post, is at the Iririki Island Resort, in Port Vila. You must take the little ferry to get to the island. So when you estimate your time to get there, make sure to factor in the water taxi time.