In some situations, there can be disagreement about whether a project should be done with an estimate, or with no estimate. Which one is the more valuable use of time and resources? Time should be spent performing different aspects of product development, but should an estimate for the overall cost be used in an example such as the following? Read the following question that was posed about this sort of circumstance for an idea of the situation:
“I was on a team recently in which we tried the no-estimate approach. Typical day for this approach played out like this: I was the product owner (and the scrum master, which is a story for another day) so I presented the scenario to the team and answered their questions. The team then spent time discussing and breaking it down into deliverables and tasks. After a series of sprints, we compared their deliverable rate to those in which they estimated. No-estimates were slightly better, but not enough to say it was clearly better (for our team) than estimating.”
The question is addressing an A/B test of sorts: a team was presented with different scenarios, and after a series of tests, they compared the delivery rate of products with an estimated delivery time against a series of products with no estimation. In this case, “estimation” represents an agreed-upon delivery time and cost for investors and product managers. So in short: is it better to set up a product with NO delivery time and cost agreed upon, or to estimate both?
There are two main sides to this story, just like there are to most issues. Let’s take a bit of time and look at each side in a bit of detail:
On the one hand, in the example listed above the “product owner” did notice a difference in the quality of the finished products, but the difference was slight and it could not completely be attributed to the fact that there was no estimation on that product. So the argument COULD be made that lack of estimation has positive results on the creation of different products.
This finding could have some merit; when a designer is given free reign to make a product any way that he or she wants, with no time or money limitations, the product has the potential to be a truly great product. No limits could indeed mean that the product turns out even better than was originally thought. However, the opposite could be true as well: no time or money limitations could also mean that a subpar product is the end result, that cost huge amounts of money and took huge amounts of time to build. Also, investors are far less likely to front money for a product when they don’t know when it will be ready AND have no idea how much it will cost.
From the other side of the argument, a team with defined goals and a finite amount of money and time may very well be the way to go in a given team. However, one does have to realize that there will be errors in the the way that the estimate is structured; delays will happen and budgets will be slightly extended. However a slightly erroneous estimate is far better than no estimate at all.
The key to a good estimate is to take a look at EVERY aspect of the product development and then carefully take that along with a bit of error into account. THEN, you will be prepared to deliver a rough estimate of time and money to the finances of the product. You are not prepared to make an estimation until you have carefully done research on the capability of your team and the full scope of your product.
Another part of this argument that must be addressed is that sometimes estimates can be abused by the product owner. Such a situation could look like this: A team provides an estimate based on a story, and the estimate is a agreed upon. After the estimate is agreed upon, the product owner could occasionally add requirements that were not in the original agreement.
So what is the conclusion of all of this? Should estimates be used, or not? And what are the benefits of doing this “the right way?”
As a general rule, it is better to have an estimation from the start. This prevents a company from having to spend far too much money on a product that took twice as long as it should have to develop. An estimation keeps everyone on schedule, and in ideal cases keeps everyone happy as well. However, a few things should be cleared up from the start: the estimate should contain a clear list of conditions, and any additional changes that are made by the product owner can change the estimate. Everyone will be in agreement about changes, if those changes push back the date of delivery or raise the budget for the product. Treat the estimate like a less-serious contract; changes should be made sparingly, if at all. If you use an estimate that is carefully modeled after the requirements of the product, the development team and the owner will get what they want, when they want it!