How long will it take: estimates without illusions
Why everyone errs in the same direction
People estimate the path where everything works. In reality, development time splits between writing the code and everything around it: integration, environments, real data, testing, fixes, and waiting on approvals and other people. The gap between the two is most of the gap between promise and reality.
How to estimate anyway
Break it into items each smaller than two days. An item hard to break down is one you don't understand, and that's where the real risk sits.
Give a range: fast, likely, bad. The gap between fast and bad measures uncertainty, and that alone is management information.
Write down what would turn the bad into the likely: a pending decision, environment access, a vendor's answer. Those are the things worth tackling first.
Measurement instead of argument
After a few work cycles you have a real number: how many items the team finishes per week. Planning based on that number is far more accurate than any estimate stated in a meeting.
Update the forecast publicly when something changes. An early surprise is tolerable; a surprise the day before the date is not.
Going deeper
Add a fixed line for invisible work: environment setup, monitoring, permissions, documentation, error handling. In projects connected to external services, this ranges between a third and half of the time — and when it's not on the list, it gets stolen from testing time.