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

1 points by harryosgood 13 hours ago

We collect “days available” each sprint (our capacity board lives in monday dev) but people still inflate the numbers.

What simple nudges or rules actually get engineers to give realistic availability? Real tactics, please, such as calendar gating, lightweight approvals, or something else?

codingdave 6 hours ago

You don't change how they are estimating, you change how you react to their estimates. This is the entire reason scrum estimates with story points, not hours/days -- so that you let the team estimate however they want, observe how many points actually get done for a few sprints, then load future sprints to that level.

And yes, if devs are off for a few days, do some arithmetic to shrink the expected velocity by whatever ratio of time you have missing people.

viraptor 12 hours ago

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.

AnimalMuppet 12 hours ago

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.

Juliate 12 hours ago

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?

sunscream89 12 hours ago

Deflate the numbers by 25-30%.

Tell them you’re “hedging.”

Get the feel for that and reappraise.