[untitled]
9 comments
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.
Estimation in engineering is famously hard to solve. Maybe the best answer is - don't.
[deleted]
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.
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.
Old article by Joel Spolsky https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
Short version: Track the predictions and the actual time to solve the task, and then use that data to adjust the new predictions to a realistic ones.
Short version: Track the predictions and the actual time to solve the task, and then use that data to adjust the new predictions to a realistic ones.
Holy f* I said a simpler version of this and got karma negged.
I didn’t say “developers routinely mis-estimate their projections by ~25% because they do not anticipate admin overhead sich as emails, phone calls, or other non technical back and fourth.” So if projections are regularly skewed hedge the projections and refine the process.
I didn’t say “developers routinely mis-estimate their projections by ~25% because they do not anticipate admin overhead sich as emails, phone calls, or other non technical back and fourth.” So if projections are regularly skewed hedge the projections and refine the process.
I don't understand why you were downvoted.
Anyway, the advantages of the Joel's method are:
1) he writes better than you and me
2) it's automatic, so there are not hard feelings or overoptimistic managers
Anyway, the advantages of the Joel's method are:
1) he writes better than you and me
2) it's automatic, so there are not hard feelings or overoptimistic managers
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.
Deflate the numbers by 25-30%.
Tell them you’re “hedging.”
Get the feel for that and reappraise.
Tell them you’re “hedging.”
Get the feel for that and reappraise.
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?