Story Point Estimation!

Myth: In Scrum, we estimate with Story Points only.
Variations:

• If you don't use Story Points, it's not Scrum
• Hour/Day estimates are evil
• We can't tell you how much it costs
• We can't tell you when it's done

Follow-up myths:

• Scrum does not permit budgeting
• Scrum doesn't let us forecast a release date
• Scrum doesn't let us define a release date

Category: General Scrum myths
Danger: High

The basis of the myth

One of the first things we learn in most Scrum trainings is: "We don't want to plan in Man-days, because that doesn't work out anyways." Tools like Planning Poker or Magic Estimation are then introduced to fill the gap, and "Story Points" are offered as an alternative. In some cases, trainers even go into great depths to explain why we use Fibonacci numbers for estimation.

New Scrum practitioners are often left with the impression that the use of "Story Points" is prescriptive in Scrum and that Man-Day or Cost estimates are against Scrum.

Why is it a myth?

As we already discussed, User Stories are not part of Scrum - and neither is "Story Point Estimation", which is clearly related to Stories.
Let's take a look at what the Scrum Guide actually says:

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value." - and, in another section: "The work done on them depreciates quickly and must be frequently re-estimated"

From a Scrum perspective, the backlog should be estimated - there are no prescriptions as to how this estimation is done.
The entire argument is a "straw man fallacy" relying on a lot of assumptions that are not related to Scrum.


Assumption #1: No effort estimation
Classic project effort estimation would define upper limits for individual tasks, such as Analysis, Development and Testing (and then suffering from Parkinson's Law). This usually results in unwanted behaviours, such as risk aversion and obfuscation.
Agile estimation tries to capture uncertainty and risk involved in the delivery of backlog items to lay them out early. It purposefully does not provide upper capacity limits. Instead, the key purpose of estimation is to provide a ballpark figure on whether something is feasible and sufficiently valuable to work on.

Assumption #2: The point of estimation is to plan delivery

No, it isn't. The entire purpose of the estimation process in an agile setting is risk management. Part of this risk management is exposing these risks and seeking solutions. The actual, estimated number may be considered merely a side benefit.

Assumption #3: We don't know how long it takes

The classic reason brought up against man-day estimation is that when facing the Unknown, nobody can know how long it will take. However, that's a key point of estimation: To know whether we're going out on a limb, taking a leap of faith, or doing something fairly reliable. We do accept that we can be wrong, and we're not in it for the best estimate. But here are a few statements we should be able to make about backlog items after estimation:

• Will it fit into one Sprint?
• If it does, will it fill the entire Sprint or take only a portion?
• If not: why do we think so?
• Can we extract something that does fit into a Sprint?

So, we do actually know "how long it takes". What we don't know yet, however, is "when it will be priority 1" - and consequently, "when it will be delivered". But if it were our priority 1, we should be able to tell pretty well how long it takes.

And once the team has completed some Sprints, they can even get a gut feeling on whether they can do 1, 5 or 20 items, so these kinds of statements even become more accurate over time.

Assumption #4: No relationship between cost and Story Points

Sometimes, you hear teams stating that due to Story Point Estimation, they have no way of giving you a cost indicator. But it's possible: Just like above, we know approximately how much capacity we'll sink into this. We also know how many people are on the team and how much each person costs us per Sprint. So, we can do some math:

Sprint Cost = (Team Size * Daily Cost per person + Daily Infrastructure Cost) * Days in Sprint 

Item Cost Estimate = (Estimate/Velocity) * Sprint Cost

While we probably can't tell whether it's going to cost $1750 or $1800, we can definitely tell you whether it's more likely to cost $5k or $500k. And low estimates mean we're closer to a lower figure, while a high estimates indicate a cost that's going through the roof.

Consequences

Unnecessary conflict

Especially in existing organizations, people are often used to estimates in hours/days. Some have even become quite adept at them. There is no need to provoke conflict with a functioning process.
"Story Point Estimation" is merely an alternative to deal with some common dysfunctions.

Business uncertainty

Business needs some kind of predictability. Even the most stout defender of Story Point Estimation wants to know how much their lunch costs and whether it'll be delivered before midnight. Business needs some degree of understanding on where the money is going, whether something is actually "worth it" and how to plan stuff such as marketing campaigns.

Anti-Collabortion

Refusal or inability to provide business relevant information will create an impression that developers are being unhelpful, completely against the collaborative spirit of agility. Story Points are not an excuse to not give business what they need.

Wrong mindset

Agile software development is intended as a means of reducing uncertainty fast and effectively. It is not intended as an excuse to avoid solvable problems. When Story Points are used as a "get out of jail free" card in the Scrum team, they are also being abused. Their intention is to provide leeway in face of uncertainty, not to create an uncertainty leeway.

Insistence on "Story Points Only" destroys agility and trust!

Remedies

Story points are not inherently bad. They only become dangerous when they turn into a "cannot" or "must not". If used in that fashion, they will quickly become a tool that will be used to bludgeon the team.

Every estimation technique and unit is acceptable, but any occurring dysfunctions need to be dealt with. When Story Points themselves become dysfunctional, go back to the root of which problems the team has to solve.

Before picking a way of estimation, create awareness of the following:

1. Who needs the estimates?
2. What are they being used for?
3. How can we provide to all who need some estimation, what they need.
4. There is no such thing as a "correct estimate".
5. The main purpose of estimation is to address risk early.
6. The value is in the conversation, not in the number.