←back to thread

388 points replyifuagree | 4 comments | | HN request time: 0s | source
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 #
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 #
1. 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 #
2. 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 #
3. ResearchCode ◴[] No.37968517[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.
4. 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.