4 ms·

Don't estimate. They don't matter and nobody cares about them anyway. If you're a sales driven/feature factory company, the estimates won't matter anyway as you

Don't estimate. They don't matter and nobody cares about them anyway. If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates. If you're a company that plans far in advance, the same is true. You'll demand the work you wanted is done at a given date, again regardless of how difficult it was. At my company, we have a well maintained backlog of work. We pick dates in the future to check in on what got done in between check ins. The product manager can (re)prioritize work as needed. We pull from the top. If there's a surprise deadline it gets brought up to everyone and then put at the top of the queue, sometimes over currently in-progress tasks. You cannot bend the realities of time and complexity. If something is hard, an estimate doesn't make it easier. A hard delivery date also doesn't bring predictability. Ultimately, with or without estimates, you'll get what you get. If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up. If every team is working optimally (they're not), hire. I'll also add, the time it takes to prepare an estimate of any value is probably 10x what anybody asking you to estimate something is willing to provide. You're being asked to spit out a number to fit an existing narrative. If you wanted to estimate a unit of work with any amount of legitimacy, you'd need hours/days/weeks (depending on SOW). These companies scheduling weekly estimation meetings that last an hour and are bullshit scrum cards don't matter and aren't interested in being even close to correct.

gregmac 5y ago
When prioritizing, it's not always obvious which items are big vs small. How do you provide that feedback to PM during prioritization? Sometimes implementing what should be a simple feature requires a month of refactoring some old technical debt. And sometimes what seems like a very complex feature is actually just a matter of enabling a flag on some third party component you're already using. All is us have likely experienced "why is x taking so long?? Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?
- void_mint 5y ago
  > When prioritizing, it's not always obvious which items are big vs small. Why does the size of the work that needs to get done matter? If you need it you need it. If you don't, you don't. If you want a fast fix, note it. Speak in outcomes. "The lowest amount of work possible to get us ________" > All is us have likely experienced "why is x taking so long?? I wouldn't work with a PM that disrespected me like that. > Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that? This isn't prioritization, it's a PM making ill-informed judgements on dev work. Don't have your PMs do that. Product people can define priority, scope, etc. If your PM isn't prioritizing something because they think it takes a long time, they do not understand their role.
  - Leherenn 5y ago
    > Why does the size of the work that needs to get done matter? If you need it you need it. Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.
    - void_mint 5y ago
      > Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.
      - Leherenn 5y ago
        But not trying something very unlikely to succeed sounds valuable to me. Why waste 2 months of engineering time if your engineering team is convinced it will take at least 6 months?
KronisLV 5y ago
> Don't estimate. They don't matter and nobody cares about them anyway. Except for when potential clients ask your company: "How much implementing a system to do X would cost?" If your company attempts to calculate this based on how many people would be needed to cover the scope and what the technical complexity of the implementation would be like, then you need to give an answer as a developer, so that the sales department can do some ballpark calculations and give a response to the clients. Especially when numerous other companies within the industry are also attempting to answer that same question. The processes and methods vary, of course, some use historical data from other projects, some use methodologies like COCOMO, others don't even ask their technical people and try to squeeze as much money from these potential clients as possible, but in the end, someone somewhere cares about the total time the project could take, ahead of time. It doesn't matter that it's almost impossible to give accurate estimates due to the nature of development (e.g. an everchanging environment with bunches of different technologies that evolve and die, as opposed to a production line of widgets) and it doesn't matter that these requirements are probably inaccurate, that they will change, that there will be scope creep and numerous other difficulties (various development decisions that will impact the project long term, many restrictions and requirements that are dependent on the environments that the clients have). In the end, i dislike estimation, clients probably don't care about any of the above and want them anyways, which leads to the development methodologies remaining "agile" in name only and estimates end up being expressed in days rather than an abstract number representation of complexity when compared to other similar tasks in that particular project.
- void_mint 5y ago
  > Except for when potential clients ask your company: "How much would implementing a system to do X cost?" And what do estimates provide here, that sales just picking a number doesn't? Estimates are made up numbers. They're estimates. Also this line that you omitted answers your question more directly: > If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.
  - KronisLV 5y ago
gumby 5y ago
> Don't estimate. They don't matter and nobody cares about them anyway. This only works for some projects. For example if your MVP or go/no go prototype costs $5MM (which a hardware or life science product easily could) you really need to know if it will be 5 or 10. I ran a company which always quoted 3X fixed price what we thought the project would really cost, even if things turned out to go wrong. Typically we made the (promised) schedule, and when not (luckily didn’t happen too often) the customer would be able to tell pretty much as soon as we could tell, and together we dealt with it. But as for the cost: most projects were extremely profitable but sometimes we would lose hundreds of thousands on them. That’s why we charged such a premium: we absorbed the financial risk (not that we ever told the customers our internal cost estimate — none of their business!)
- void_mint 5y ago
  Hardware and life science projects usually have more time to research and prepare than the hour of weekly estimation provided by silly agile orgs. Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter? As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.
  - gumby 5y ago
    > Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter? Most of the time, in my experience. At a bigger company that may not matter so much but at a startup it can be fatal.
  - smichel17 5y ago
    > As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free. Knowing how far you'll get might affect what you prioritize, no?
erdo 5y ago
> If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up Exactly, the answers might surprise you

gregmac 5y ago

When prioritizing, it's not always obvious which items are big vs small. How do you provide that feedback to PM during prioritization? Sometimes implementing what should be a simple feature requires a month of refactoring some old technical debt. And sometimes what seems like a very complex feature is actually just a matter of enabling a flag on some third party component you're already using. All is us have likely experienced "why is x taking so long?? Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

void_mint 5y ago
> When prioritizing, it's not always obvious which items are big vs small. Why does the size of the work that needs to get done matter? If you need it you need it. If you don't, you don't. If you want a fast fix, note it. Speak in outcomes. "The lowest amount of work possible to get us ________" > All is us have likely experienced "why is x taking so long?? I wouldn't work with a PM that disrespected me like that. > Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that? This isn't prioritization, it's a PM making ill-informed judgements on dev work. Don't have your PMs do that. Product people can define priority, scope, etc. If your PM isn't prioritizing something because they think it takes a long time, they do not understand their role.
- Leherenn 5y ago
  > Why does the size of the work that needs to get done matter? If you need it you need it. Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.
  - void_mint 5y ago
    > Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.
    - Leherenn 5y ago
      But not trying something very unlikely to succeed sounds valuable to me. Why waste 2 months of engineering time if your engineering team is convinced it will take at least 6 months?

KronisLV 5y ago

> Don't estimate. They don't matter and nobody cares about them anyway. Except for when potential clients ask your company: "How much implementing a system to do X would cost?" If your company attempts to calculate this based on how many people would be needed to cover the scope and what the technical complexity of the implementation would be like, then you need to give an answer as a developer, so that the sales department can do some ballpark calculations and give a response to the clients. Especially when numerous other companies within the industry are also attempting to answer that same question. The processes and methods vary, of course, some use historical data from other projects, some use methodologies like COCOMO, others don't even ask their technical people and try to squeeze as much money from these potential clients as possible, but in the end, someone somewhere cares about the total time the project could take, ahead of time. It doesn't matter that it's almost impossible to give accurate estimates due to the nature of development (e.g. an everchanging environment with bunches of different technologies that evolve and die, as opposed to a production line of widgets) and it doesn't matter that these requirements are probably inaccurate, that they will change, that there will be scope creep and numerous other difficulties (various development decisions that will impact the project long term, many restrictions and requirements that are dependent on the environments that the clients have). In the end, i dislike estimation, clients probably don't care about any of the above and want them anyways, which leads to the development methodologies remaining "agile" in name only and estimates end up being expressed in days rather than an abstract number representation of complexity when compared to other similar tasks in that particular project.

void_mint 5y ago
> Except for when potential clients ask your company: "How much would implementing a system to do X cost?" And what do estimates provide here, that sales just picking a number doesn't? Estimates are made up numbers. They're estimates. Also this line that you omitted answers your question more directly: > If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.
- KronisLV 5y ago

gumby 5y ago

> Don't estimate. They don't matter and nobody cares about them anyway. This only works for some projects. For example if your MVP or go/no go prototype costs $5MM (which a hardware or life science product easily could) you really need to know if it will be 5 or 10. I ran a company which always quoted 3X fixed price what we thought the project would really cost, even if things turned out to go wrong. Typically we made the (promised) schedule, and when not (luckily didn’t happen too often) the customer would be able to tell pretty much as soon as we could tell, and together we dealt with it. But as for the cost: most projects were extremely profitable but sometimes we would lose hundreds of thousands on them. That’s why we charged such a premium: we absorbed the financial risk (not that we ever told the customers our internal cost estimate — none of their business!)

void_mint 5y ago
Hardware and life science projects usually have more time to research and prepare than the hour of weekly estimation provided by silly agile orgs. Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter? As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.
- gumby 5y ago
  > Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter? Most of the time, in my experience. At a bigger company that may not matter so much but at a startup it can be fatal.
- smichel17 5y ago
  > As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free. Knowing how far you'll get might affect what you prioritize, no?

erdo 5y ago

> If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up Exactly, the answers might surprise you