Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.
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.
Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.
See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.
As a developer, I endorse doing as little as possible as a result.
Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that
If management is pushing for lower estimates, it's typically going some reason along the lines of:
- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.
- They're expecting market conditions to reward earlier delivery more than higher quality.
- They don't understand the problem domain.
- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.
If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.
If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.
Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.
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.
Have you ever seen developers overestimate their tasks? On what kind of alternative dimension this happens?
Developers are always deluded optimists that can't get realistic estimates no matter how much they inflate it.
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.
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them
my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.
Can you cite your own statistics? But even granting your assertion, it still would not matter because in the end the project will be done sooner the more pressure is put on, so it's better to underestimate and plan for delays than to over estimate. Managers often have two different deadlines for projects: the official deadline, and the real deadline. They simply don't tell their reports the real deadline. At many tech companies it's not unusual that a team will only make 70%-90% of their OKRs, and if they consistently make 100% they are said to be too conservative in their ambitions and encouraged to do more.
> this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
I believe my intention was clear from the other responses I got that understood what I was saying. But that's not just what management believes, I also believe that, so your version would not be a better expression of what I meant.
here is one source that appears to be neutral:
https://blog.gitnux.com/software-project-failure-statistics/
another that suggests one third of completed projects have cost or time overrun:
https://www.bcs.org/articles-opinion-and-research/a-study-in...