4 ms·

The need to estimate highly depends on whether you are developing a project or a product. On a project, the customer always wants to know what will be done at w

The need to estimate highly depends on whether you are developing a project or a product. On a project, the customer always wants to know what will be done at which date, and how much that would cost. A product however, can be released "when it's done", so there is no real need to estimate. The additional benefit is also that it can be released when the developers feel that the product is ready for release, unlike a project, where there is a lot of pressure to deliver things. My personal view (and experience) is that developing without estimates saves time and creates a higher quality product. But other (smart) developers that I know like to work within estimates because they think it pushes everyone to deliver things. We probably are both right, because there is yet another factor that comes into play when choosing to estimate or not: motivation of the developers. Highly motivated developers who love their job, rather work in their code instead of goofing off on the internet. But when the project/product is not that special, and not everyone feels passionate about it, estimating and follow-up is probably preferred to put a little pressure on getting things done.

UK-AL 12y ago
Estimates should never be used to apply pressure(people take shortcuts), they should always try to reflect reality. In products estimates are used to work out which features provide the most value, in the shortest amount of time.
- dreamfactory2 12y ago
  > In products estimates are used to work out which features provide the most value, in the shortest amount of time. And this is why there is actually no difference between a product and a project. But value doesn't depend on estimates at all, as there may be many different ways to implement. Calculating value is therefore more important than estimating net value for any specific implementation - it tells you what your direction of travel should be.
- koonsolo 12y ago
  > In products estimates are used to work out which features provide the most value, in the shortest amount of time. With products, estimating the value of a feature is even harder than estimating the implementation time/cost. And calculating the future revenue of your product is also harder than calculating the future implementation cost. You might argue that your product must be finished before you run out of money (which you can calculate with estimates), but MVP's don't rely on estimates that much and you can test your product/market fit at the same time. In theory, product profitability and selecting features seems highly depend on estimates, but in practice I always saw that gut feeling was good enough, for both features and how long a development will take. You can't drop the must-have features, and nice to haves can be implemented after your first release.
jiggy2011 12y ago
Sure, but you need to release before you run out of money. You also need to cost/benefit a feature which is hard to do without any sort of estimate.
- jacques_chester 12y ago
  I'm a fan and student of estimation techniques, but this is more of an argument for always having releasable software.
slgeorge 12y ago
> A product however, can be released "when it's done", so there is no real need to estimate. > The additional benefit is also that it can be released when the developers feel that the product is ready for release, > unlike a project, where there is a lot of pressure to deliver things. This view probably depends on your definition of "estimate", whether it's being done at an individual developers level or whether it's being done at a team/product level. For team/product level (as another commentator mentioned) if you don't have a cost/benefit analysis then you don't know if the work being done is worth doing, and you may run out of money before your product is "done". Additionally, (the article mentions this but it's worth expanding on) other bits of the organisation need to co-ordinate and depend on knowing status and when the product will be ready. To take an extreme example an enterprise software company might need to know with more than six months notice in order to start planning and preparing sales, marketing and PR teams for the coming release.

UK-AL 12y ago

Estimates should never be used to apply pressure(people take shortcuts), they should always try to reflect reality. In products estimates are used to work out which features provide the most value, in the shortest amount of time.

dreamfactory2 12y ago
> In products estimates are used to work out which features provide the most value, in the shortest amount of time. And this is why there is actually no difference between a product and a project. But value doesn't depend on estimates at all, as there may be many different ways to implement. Calculating value is therefore more important than estimating net value for any specific implementation - it tells you what your direction of travel should be.
koonsolo 12y ago
> In products estimates are used to work out which features provide the most value, in the shortest amount of time. With products, estimating the value of a feature is even harder than estimating the implementation time/cost. And calculating the future revenue of your product is also harder than calculating the future implementation cost. You might argue that your product must be finished before you run out of money (which you can calculate with estimates), but MVP's don't rely on estimates that much and you can test your product/market fit at the same time. In theory, product profitability and selecting features seems highly depend on estimates, but in practice I always saw that gut feeling was good enough, for both features and how long a development will take. You can't drop the must-have features, and nice to haves can be implemented after your first release.

jiggy2011 12y ago

Sure, but you need to release before you run out of money. You also need to cost/benefit a feature which is hard to do without any sort of estimate.

jacques_chester 12y ago
I'm a fan and student of estimation techniques, but this is more of an argument for always having releasable software.

slgeorge 12y ago

> A product however, can be released "when it's done", so there is no real need to estimate. > The additional benefit is also that it can be released when the developers feel that the product is ready for release, > unlike a project, where there is a lot of pressure to deliver things. This view probably depends on your definition of "estimate", whether it's being done at an individual developers level or whether it's being done at a team/product level. For team/product level (as another commentator mentioned) if you don't have a cost/benefit analysis then you don't know if the work being done is worth doing, and you may run out of money before your product is "done". Additionally, (the article mentions this but it's worth expanding on) other bits of the organisation need to co-ordinate and depend on knowing status and when the product will be ready. To take an extreme example an enterprise software company might need to know with more than six months notice in order to start planning and preparing sales, marketing and PR teams for the coming release.