3 ms·

Even 1.) is very hard to estimate, and info from people who did something similar is of quite limited value. Skills, technical environment (system, programming

Even 1.) is very hard to estimate, and info from people who did something similar is of quite limited value. Skills, technical environment (system, programming language, libraries, available tooling) and team efficiency vary A LOT. -- Regarding your comment of overestimation: I think this is a problem for almost everyone. When you get a task described, you often think "hey, this will be easy", without understanding all the requirements in detail, the complexity it will entail or the broader effects in a system. That's where only experience can help (your own or someone elses input)

gh1 10y ago
On a different note, I have heard it being said that it is better to overestimate than underestimate. This is apparently the best way to manage other people's expectations and maintain credibility.
- matwood 10y ago
  Over is probably the wrong word. I call it realistic estimation. Every stakeholder/business person wants it done yesterday. Their job is to push and prod and squeeze out as much efficiency as possible. It's the estimators job to give a realistic estimate, which often means pushing back to a lot of pressure, and that can be very hard. It's important to realize the most important thing for the business is an estimate as close to reality as possible though. This point is often missed when there is pressure to estimate it shorter, when in fact it is not the estimate the business person wants shorter, but the complete task. And yes, it does take time to build that trust. Often times when I'm at a new company, the business people are used to short estimates and overruns. I have to train them to understand that while my estimates are longer, they are typically closer to correct. It only takes once or twice of having something done when expected to win them over.
  - MaulingMonkey 10y ago
    > Over is probably the wrong word. I call it realistic estimation. I generate realistic estimations by attempting to overestimate and failing to do so sufficiently. Watching coworkers try to estimate how long it'll take to deliver software really makes you wonder if pessimists actually exist, or if they're rather some kind of myth or mirage.

gh1 10y ago

On a different note, I have heard it being said that it is better to overestimate than underestimate. This is apparently the best way to manage other people's expectations and maintain credibility.

matwood 10y ago
Over is probably the wrong word. I call it realistic estimation. Every stakeholder/business person wants it done yesterday. Their job is to push and prod and squeeze out as much efficiency as possible. It's the estimators job to give a realistic estimate, which often means pushing back to a lot of pressure, and that can be very hard. It's important to realize the most important thing for the business is an estimate as close to reality as possible though. This point is often missed when there is pressure to estimate it shorter, when in fact it is not the estimate the business person wants shorter, but the complete task. And yes, it does take time to build that trust. Often times when I'm at a new company, the business people are used to short estimates and overruns. I have to train them to understand that while my estimates are longer, they are typically closer to correct. It only takes once or twice of having something done when expected to win them over.
- MaulingMonkey 10y ago
  > Over is probably the wrong word. I call it realistic estimation. I generate realistic estimations by attempting to overestimate and failing to do so sufficiently. Watching coworkers try to estimate how long it'll take to deliver software really makes you wonder if pessimists actually exist, or if they're rather some kind of myth or mirage.