Scrum points and tine - question often asked

It is a very common question to be asked: Why estimate in scrum is given in scrum points instead of time/money.

This answer is my personal opinion and many might disagree with some of the points - feel free to comment bellow.

In short - it is by purpose to disconnect fixed money, fixed content, fixed time, fixed work-hours, high expectations, uncertain estimate and unpredictable future. Without it estimation would be used as fixed price and no one would take the risk into account.


First of all let's look how development process usually works.
On the top there is the customer - who wants to pay for something usable (or someone wants to sell it to him). He wants the feature delivered on time without issues for money he is willing to pay.
On the bottom there is someone to prepare the product. But customers usually will focus on their expectations and not how it is made. Just like at the restaurant when you don't need to look at the cook (otherwise it would cost a lot).
And there are many layers in the middle. When it comes to the software development you might see large costs, long development time, significant complexity, unclear expectations and huge amount of uncertainty.

So we have (try thinking about a restaurant instead of software development):

• The customer focused on own expectations, delivery time and cost. Often payment is made after product/dish delivery (and consumption).
• Someone to do the marketing (ex. give you an invitation with a discount and say that this is the best restaurant in the town). Someone (waiter) to sell (suggest) and deliver the product.
• Someone to make the investment (restaurant is not cheap to build/finish).
• Someone to watch the staff. He expects his staff to prepare a flawless meal.
• Someone to prepare the dish. This is probably the worst job in this chain: most demanding and least paid. And manager is always shouting at you. What if you run out of the ingredients?

In software development it works in a similar way:

• Customer ordered a product.
• Sale person sold the product (often having no technical knowledge making a promise that cannot be kept).
• Investor is counting money. Return of investment, cost, risk - those are the words here.
• Manager is expected to provide how much will it cost and when it will be delivered. No one cares about the quality - everyone expects it to be flawless.
• Software developers prepare the product. You already got the reasoning here?

Let's change the order. Chronologically.

Sales person who already promised something without having that. Worst kind of person would say that the product is ready and just need to be deployed (although development wasn't started yet).

Customer who has a rough view on the expected result is probably unaware of the details - and this is the person who should clearly state expectations so that someone else can work on it. Customer expects the feature soon.

Manager asks "how long it might take". But what he wanted to ask is "what cost/time I must pass to my supervisor". And what he should ask is rather "What can I do to make everyone happy and how long it might take".

Developer provides a rough estimation of how long it could take (and not much is known at this phase). Note that it is not certain.

Manager takes the estimate and puts it into the plan/schedule. If he is a bastard then he might ask several developers for the estimate and take the lowest estimates coming from every developer alone mixed together.

Investor grants the budget. Risk management takes place here. Often there would be no deal if we had no customer what leads to the fact that sales person is first.

What often happens is:

Developer gives an estimate for some items. Customer expectations are not yet defined so there is no way to predict all the obstacles at this stage. Estimation has huge risk involved.

Manager takes the estimates without any risk management and taking into the account sunny day scenario.

Sales person already sold a product - although it is not yet ready.

Investor counts only the expected return of investment and return date.

Customer... we lost the customer somewhere in between.

After all the development team is expected to deliver on time, with quality and cheap.

Every step has its own key units to watch. Customer has the expectations, sales is out of the case as product is already sold, investor has the budget.

Who took the risk?

Customer would rise a hand - as he risked working with us (eating at our restaurant). Sales person risked the reputation... or whatever. Investor risked the money. Manager risked nothing. Developer took the risk of estimation.

Process started with product being sold and would end with all the tasks being complete. We expected it to be a complete package.

At this point we step in with the scrum points. Development team provides an abstract unit that is not directly convertible to man-hours, time, head-counts, money.... and the value is known to change over time. So we are pushing towards a different model. The development team can work closely with the customer, deliver small pieces of the product frequently and gathering feedback immediately. No one considered the quality - so it is up to discussion. Since we have immediate feedback we have lowered the risks. Customer is not given a fixed cost or time (might be aware of a high level values) but can decide where to put efforts and what is the level to satisfy the needs.

It is not possible to plan all the product as estimation values are too abstract.

So please, do NOT try to create a magic formula of an ideal man and an ideal workday for ideal product to convert scrum points into money. Either go for the waterfall (and prepare to overpay a lot) or accept that model.

Please, let me know what do you thing about that.