We like to underpromise and overdeliver. If we don't pad, we become very late. I have heard some PM's especially on 1.0 projects that are much more difficult to predict will multiply the estimate by 3x sometimes. I would love to hear what other PMs do on padding their estimates.
Add Slack and Remove Fear; Garnish with Trust; Stir Well and Serve
There can't be a single, canonical answer to this question except "Maybe you shouldn't." It really depends on what you're optimizing for. If your project has a lot of known-unknowns or unknown-unknowns, then you can't really fix that with padded estimates. Instead, you need to address those issues head-on during project initiation, or through techniques like story spikes or iterative decomposition of the work.
With that said, some common techniques for avoiding overruns (with analogs in many different frameworks) include:
- Using relative estimates, and rounding up to the nearest Fibonacci number.
- Using the "Scotty principle" and multiplying all your estimates by 200-400%.
- Applying fudge factors like 0.6 or 0.8 to velocity estimates based on things like newness of the team or complexity of the problem domain.
- Using statistical ranges for estimates, rather than fixed-value estimates.
- Adding slack to all work packages.
The problem with all of these approaches (as well as others) is that they each solve for certain assumptions, whether spoken or unspoken. In your case, the unspoken assumption is that Bad Things℠ will happen to you or the team when estimates are treated like money-back guarantees.
Rather than trying to pad your estimates, I'd recommend the following:
- Ensure estimates are treated as probability forecasts with acknowledged margins of error.
- Give the team sufficient political backing to make honest estimates, with the expectation that estimation will become more accurate (but never exact) over time.
- Treat missed estimates as validated learning opportunities, not blame-and-deflect exercises.
- Use iterative, incremental, or just-in-time planning along with time-and-materials budgeting to avoid the whole issue in the first place.
- Make sure that the project team has sufficient slack in every aspect of its process to create flex.
When people on a project are afraid to be honest in their estimates there is usually a political or process problem in play. Root that out vigorously; reward honesty, collaborative problem-solving, and effective communications rather than sweeping problems under the rug with inflated estimates.
Estimation is a big topic but I think the best answer here is also the simplest: use relative estimation techniques (story points and measured velocity) rather than absolute estimation. Relative estimates tend to be more accurate, make it easier to set accurate expectations and there's no need to pad out your estimates if you track velocity over time. Padding is only relevant for absolute estimates.
My assumption is that you take a continuous/iterative delivery approach to software development.