Ask HN: How do you stop teams from overestimating sprint capacity?

Why fight people? If you already have the data on overestimation, why not produce numbers adjusted based on the previous experience?

Estimation in engineering is famously hard to solve. Maybe the best answer is - don't.

Deflate the numbers by 25-30%.

Tell them you’re “hedging.”

Get the feel for that and reappraise.

Measure. Measure how much you actually get done in each sprint. If the team is regularly saying that they can do 20 points of work, but they only get 15 done, then they should only be signing up for 15 points of work in each sprint, no matter how much they think they can do 20.

1/ any day that includes a single meeting (related or not) should be marked as fully unavailable.

So if you have planned meeting in a week, group them (but not all of them on a single day either) and mark that day as unavailable. That usually already reduces a week of work to 4 days.

Then it's usually more on the longer term, but you (well, each dev actually) may benchmark continuously previous estimates against reality, so that they can understand their bias over time.

2/ do delegate approvals with a few basic rules: have a (short) rationale written down for each decision taken without a n+1 request; should be reversible if it's important.

3/ how long are your sprints usually?