Hacks for Engineering Estimates
shubhro.com
Hacks for Engineering Estimates
1–10 of 41 posts
Re: Hacks for Engineering Estimates
#2Interesting article.
Our PO often almost demands estimations from us. Usually I am already responding in a best/worst case fashion.
In the end PO only seems to remember the best case and takes it as commitment. Since I was fooled by this a few times, I am now collecting a paper trail and am quiet reluctant, when giving "just a ballpark figure".
My key takeaway was, that estimations mostly aren't about accuracy or getting a value, but rather managing people's expectations and navigating corporate politics.
Re: Hacks for Engineering Estimates
#3The best estimation tactic I've found in practice is ROPE, which works because it helps different kinds of stakeholders understand different kinds of estimates and ranges.
R = Realistic estimate. Based on work being typical, reasonable, plausible, and usual.
O = Optimistic estimate. Based on work turning out to be notably easy, or fast, or lucky.
P = Pessimistic estimate. Based on work turning out to be notably hard, or slow, or unlucky.
E = Equilibristic estimate. Based on 50% probability suitable for critical chains and simulations.
Re: Hacks for Engineering Estimates
#4I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.
Re: Hacks for Engineering Estimates
#5I really like "3 point estimates". Rather than a single estimate you give three - one that's your expected timing, one for the best case if everything goes perfectly, and one absolutely worst case scenario time. The difference between "best case and expected", and "worst case and expected", indicate the risk factor. If best case and expected are similar then it's a low risk feature - you understand the complexity and there are few unknowns. If the worst case and expected are similar then it's a high risk feature that you don't expect to go to plan.
I've never been in a position to actually use this approach well, but I like the idea of it a lot.
Re: Hacks for Engineering Estimates
#6Using Steve McConnell's terms, I think of things playing out as Plan, then Estimate, then discuss the Target, and then cut features before Committment.
Having multiple people independently estimate a given problem is a more robust way to estimate, in general. Other than as a lead and a dev each sizing something up, I don't think I've seen that in practice. It feels a little weird for developers to be estimating each other's work. I think it's interesting if and only if Committment is truly separated from estimation.
Re: Hacks for Engineering Estimates
#7I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.
Wow this is so true. Never thought about it like this, but as a product manager myself you are absolutely right.
Re: Hacks for Engineering Estimates
#8When I make an estimate, I just double what I think it is and this is usual pretty accurate. I keep underestimating, sometimes doubling down I wonder myself, will it really take this long? 99% of the time, in the end, the answer was yes. So this is my goto method. People still think I finish stuff quick, even if I think myself it's too long.
Re: Hacks for Engineering Estimates
#9Things, IMO, which are spoilers:
1. Starting with an End date and create a plan from there. Some top leads want to get promoted and want to achieve X by this quarter or next.
2. With so many people leaving, there is not enough time and resources to onboard new folks, who are accounted in deliveries
3. Too many parallel initiatives
4. Unstable production taking daily attention
5. Not able to priortise tech debts over business features
6. Decision makers at top don't have grass root visibility or don't want to have.
Re: Hacks for Engineering Estimates
#10When estimating a software project of any size, try to imagine the most optimistic number of hours needed for each activity you can think of.
Then multiply by 4.14.
This provides room for
Phase 1: First verions of the deliverable: xpi/2
Phase 2: Trying to work around all the cases where the initial design was bad: xpi/2
Phase 3: Re-factor from scratch (with the same team) : x1
Sum phase 1-3 : x(pi+1)
This is for facing the customers/stakeholders. When facing the team, only present them with Phase1, with the estimate of xpi/2.
Otherwise, phase 1 alone will take x(pi+1).