←back to thread

388 points replyifuagree | 9 comments | | HN request time: 0.578s | source | bottom
Show context
zeroCalories ◴[] No.37965404[source]
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
replies(7): >>37965441 #>>37965475 #>>37965710 #>>37965713 #>>37965717 #>>37966081 #>>37969203 #
1. ejb999 ◴[] No.37965475[source]
>>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret.

...and nobody gets faulted by management, because they completed the story in the time they committed to.

On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.

replies(4): >>37965773 #>>37965956 #>>37966047 #>>37966837 #
2. ◴[] No.37965773[source]
3. rightbyte ◴[] No.37965956[source]
Ye. If the estimates are accurate they will be overrun about 50% of the time. Punishing "late" tickets is what leads to the outcome of having to pad the estimates as much as possible.
4. DiskoHexyl ◴[] No.37966047[source]
Predictability is arguably more important than speed, especially when you have a lot of moving parts. When you have a developer that is slow, but constantly delivers on his estimates, you have a reliable IC that you can count on not failing to develop an API for some other team to integrate with. Fast and ambitious guys, who frequently fall behind their own estimates, are a pain in the ass to manage in large teams/companies.

Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that

replies(1): >>37966566 #
5. orwin ◴[] No.37966566[source]
Fast and ambitious guys, who frequently fall behind their own estimates

I wasn't particularly fast, but I was this guy for a year. You're exactly right.

6. ResearchCode ◴[] No.37966837[source]
How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.
replies(2): >>37967044 #>>37969816 #
7. ejb999 ◴[] No.37967044[source]
I agree, but a lot of big companies are all in on Agile and you (as a developer) don't really get a lot of say on the matter.

Some high-paid consultants got paid a lot of money to sell it to the CEO, who then mandates it....so we are stuck with it ...until those same consultants have some other methodology-du-jour to sell.

replies(1): >>37968517 #
8. ResearchCode ◴[] No.37968517{3}[source]
Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.
9. P_I_Staker ◴[] No.37969816[source]
In my view, it's fine if it's not treated a performance metric, for the individual devs.

I saw a lot of questionable tactics stem from this. It's like when you play capture the flag, and focus on the "KDR" metric, as is often done.

Critical people who were saving the teams life and working their fucking asses off would get grilled and questioned; not intentionally, but as a natural extension of these processes. Meanwhile, people that scored easy points would get a pat on the head, then sit silently during the sprint review; thankful that they got the easy path this sprint.

It got to the point of absurdity. I think it could make sense to look at sprint points during planning, but then the total bank of points goes to the team; who scored what should be anonymous... this was one of those ideas you have that you know you can never share, lol.