31–40 of 388 posts
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.
As a developer, I endorse doing as little as possible as a result.
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.
My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniq…
>X - number of new tools, libraries, techniques, used in the process How would you know this before starting dev work?
Shipping a Vaticle + Haskell on nixOS in your own server farm?
Maybe that's more new tools for the team...
A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders. I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day. > There is back-an…
>but this is the issue addressed with planning poker. It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given.…
It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.
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.
>>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 i…
1975: Fred Brook's wrote[1]: “The bearing of a child takes nine months, no matter how many women are assigned.” Can't get better than this [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
At least you get to estimate.