A buffer cannot repair a weak estimate
If the scope is unknown, the technology has not been checked or a critical dependency is unresolved, adding 20% does not remove the problem.
Name large unknowns first. Discovery or clarification is often more valuable than a larger buffer.
Capacity and buffer are not the same
If a developer works eight hours but can spend six hours on this project, use six hours as daily capacity.
The other two hours are not risk. They are part of the normal working day.
A buffer is better suited to small fixes, minor technical issues, above-normal context switching, short communication delays and other limited variation.
Is there a good percentage?
There is no percentage that fits every project.
- 0–5% can make sense for familiar, repeatable work with little uncertainty.
- 10–15% can be a practical starting point for ordinary project work with modest uncertainty.
- 20–30% signals a higher level of uncertainty that should be discussed explicitly.
If you need a much larger margin, check whether important information is missing from the estimate. These ranges are planning guidance, not rules.
Show a base date and a recommended date
The earliest delivery date comes directly from effort, capacity and the working calendar. A recommended date includes an additional margin.
Showing both makes the assumption visible: one date describes the baseline, while the other is safer for communication.
Keep known work out of the buffer
If the client needs five days to approve the work, schedule five days for approval. Do the same for QA, deployment, data migration or external sign-off.
Known activities belong in the plan. The buffer is for limited uncertainty, not undisclosed work.
Use the Delivery Date Calculator to compare both dates, and read Deadline vs Delivery Date before making a commitment.