It is virtually impossible to give an estimate on a big project, especially if it has parts that are unseen/unknown to most or all the members of the team. How can you estimate how long it would take you to do something you have never done before? Even with the doubling technique you mentioned, although it is a good one, but still would not work in some cases..
I might just write an article of my own to discuss this issue further..
I enjoy making things to solve problems or just for curiosity's sake. When I am not overthinking things I manage to jot a few posts down which you can find here on devto.
Definitely, the larger the project, the likelier the estimates are off. At that point, its easier to focus more on the time estimates for the individual components, and try divert whatever time "saved" to parts that need more time than budgeted. Easier said than done though!!
Yes it's problematic because some organizations want to know the overall cost before embarking on a multi-year project. That's a hard number to pin down often. It's maybe easier to set a burn rate and a 5 year horizon for those cases rather than trying to pin down the cost from a early set of features that may change in the intervening years.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The 5 days trick seems interesting.
It is virtually impossible to give an estimate on a big project, especially if it has parts that are unseen/unknown to most or all the members of the team. How can you estimate how long it would take you to do something you have never done before? Even with the doubling technique you mentioned, although it is a good one, but still would not work in some cases..
I might just write an article of my own to discuss this issue further..
Well, it's also important to push for an MVP. If it's that ill-defined, then maybe lets focus on the first phase first and estimate the second later?
The larger the project is, the more likely your estimates will be off.
Definitely, the larger the project, the likelier the estimates are off. At that point, its easier to focus more on the time estimates for the individual components, and try divert whatever time "saved" to parts that need more time than budgeted. Easier said than done though!!
Yes it's problematic because some organizations want to know the overall cost before embarking on a multi-year project. That's a hard number to pin down often. It's maybe easier to set a burn rate and a 5 year horizon for those cases rather than trying to pin down the cost from a early set of features that may change in the intervening years.