4 ms·

There's some world-shaking insight. The best piece of advice I can give is to never, ever give an estimate to stakeholders until you've worked on the estimate

There's some world-shaking insight. The best piece of advice I can give is to never, ever give an estimate to stakeholders until you've worked on the estimate first. And don't finish an estimate until you've actually built some small proofs of concept. Your estimates will still be wrong, but they'll be much more accurate than some off-the-cuff number that your stakeholders will be building their various plans around. It all sounds straightforward, but the hardest discipline for me as a developer is to keep from saying things in stakeholder meetings that make my stakeholders happy in the moment, but ultimately needed more thought and effort. It's something I struggle with in every such meeting, to varying degrees of success.

hluska 11y ago
I think this is a symptom of a fear of "I don't know." If I could change one thing in dev cultures, I would instill a healthy respect for the sentence: "I don't know, but here's $how_I'll_find_out and here's $when_I'll_have_an_answer."
- ChuckMcM 11y ago
  Exactly right. Too often I've seen people commit to a schedule where the milestones were of unknown difficulty. When cutting through a new jungle, you have no idea what is between you and your goal, so really all you can say is that the best you can hope for is X if this jungle happens to be like previous ones. This is especially true in startup situations where you are learning technologies that may themselves not be complete, with people who are learning their own new things, to achieve a result which is only hypothetically possible. It drove my CFO nuts but rather than commit to a schedule for a big deliverable I would walk backwards from the end point and say, "These are the stops between where we are, and where we are going. We measure our progress by getting to each stop, but like a subway map there isn't a known amount of time between stops, only what the stops are." And he would come back with "well we only have money to get to this date, will it be done by then?" and then we would talk about the uncertainty between each of the milestones. At some point you can reach a common understanding of what the unknowns are and how discovering their value will inform on the difficulty of the next step. That said, I've met managers who just say "Oh we will be done by %x date." and then basically worked the problem the same way I have. If you're agile you can break down the intermediate stops as sprints but estimating the backlog is still the killer step.
  - brianwawok 11y ago
    It's not agile to list out 32 milestones on the way to completing a project and estimate them up front. It's agile to list 32 steps and estimate the first step, which you will still get wrong.
  - deleted 11y ago
    [deleted]
powertower 11y ago
Skimming over it, there seems to be much more specific details and insights in the body of the analysis. The conclusion does not accurately reflect that... Which seems to be more of a "recommendation" than a takeaway or a real summery.

hluska 11y ago

I think this is a symptom of a fear of "I don't know." If I could change one thing in dev cultures, I would instill a healthy respect for the sentence: "I don't know, but here's $how_I'll_find_out and here's $when_I'll_have_an_answer."

ChuckMcM 11y ago
Exactly right. Too often I've seen people commit to a schedule where the milestones were of unknown difficulty. When cutting through a new jungle, you have no idea what is between you and your goal, so really all you can say is that the best you can hope for is X if this jungle happens to be like previous ones. This is especially true in startup situations where you are learning technologies that may themselves not be complete, with people who are learning their own new things, to achieve a result which is only hypothetically possible. It drove my CFO nuts but rather than commit to a schedule for a big deliverable I would walk backwards from the end point and say, "These are the stops between where we are, and where we are going. We measure our progress by getting to each stop, but like a subway map there isn't a known amount of time between stops, only what the stops are." And he would come back with "well we only have money to get to this date, will it be done by then?" and then we would talk about the uncertainty between each of the milestones. At some point you can reach a common understanding of what the unknowns are and how discovering their value will inform on the difficulty of the next step. That said, I've met managers who just say "Oh we will be done by %x date." and then basically worked the problem the same way I have. If you're agile you can break down the intermediate stops as sprints but estimating the backlog is still the killer step.
- brianwawok 11y ago
  It's not agile to list out 32 milestones on the way to completing a project and estimate them up front. It's agile to list 32 steps and estimate the first step, which you will still get wrong.
- deleted 11y ago
  [deleted]

powertower 11y ago

Skimming over it, there seems to be much more specific details and insights in the body of the analysis. The conclusion does not accurately reflect that... Which seems to be more of a "recommendation" than a takeaway or a real summery.