The Fallacies of Scrum with Story Points

If being granted the title of ‘Master’ by passing a multiple choice exam following a two-day course does not look suspicious to you, read on.

Scrum has a number of fallacies which should get you thinking about whether companies who adopt this model succeed because of Scrum, or despite of Scrum.

Fallacy 1: Its Efficacy can never be Proven

Since Scrum is an unscientific methodology it can never be scientifically proven to work.

So you might hear someone say “it works for us”, but the fact is that such a statement can never be backed by science.

The unscientific aspect stems from the abstract way Scrum uses to try to quantify the ‘effort’ required to carry out a task.

The latest definition of ‘effort’ I saw is that of:

Effort = Complexity + Amount of Work + Degree of Risk + Level of Uncertainty

So, how does one measure ‘Complexity’, the ‘Amount of Work’, the ‘Degree of Risk’, and the ‘Level of Uncertainty’? And how do you add them up all together to arrive at an estimate?

To make these estimates even more spurious, they are restricted to specific values, picked up from an adaptation of the Fibonacci series, referred to as ‘story points’.

Therefore, in the absence of a solid method for the measurement of ‘effort’, what one person thinks a ‘story point’ represents, is most often not the same as what another person thinks.

‘Effort’ is not even a recognized form of quantity, and ‘story points’ not a recognized unit, such as metre is for length, kilogram is for weight, or hour is for time. There are no scientifically recognized units for ‘effort’: any such attempt is the fruit of imagination.

Thus any kind of measurement of ‘effort’ is spurious by design.

Also there is no way how to determine how much of the ‘story points’ allotted to a task have been actually consumed. So there is no way to determine whether the estimation was correct, even after task completion!

With time estimations however, this is entirely possible, since the actual time taken by a task can be compared to the estimated time, and the reasons leading to such a discrepancy can be identified.

Fallacy 2: Achieving the Sprint Goals in Time is either Pointless or Unattainable

Scrum involves a team selecting a number of tasks to be carried out in a specific calendar period, referred to as ‘Sprint’.

However the relationship between the aggregate of the time required to carry out the individual tasks will almost always be less than or larger than the duration of the ‘Sprint’ period.

Most often it will be either of the scenarios below.

Scenario 1: the aggregation of the time required for each task is larger than the capacity of the week.

In retrospective meetings, the team might try to identify the reasons why the ‘Sprint’ goals were not achieved, but this is completely futile since the time required for the completion of the tasks is larger than that available in the ‘Sprint’.

The reason might be stated that Task 5, (or any other task) should have been split into smaller tasks. But, how would one know in advance? And tasks should only be split if it makes sense to do so, not to make them fit in an artificial deadline as a ‘Sprint’.

Scenario 2: the aggregation of the time required for each task is less than the capacity of the week.

This might prompt the team to celebrate that the ‘Sprint’ goals were achieved, but in reality this was just the obvious outcome: the total time required to do all the tasks simply fits in the ‘Sprint’ period.

Fallacy 3: Unreliable Task Estimations

As noted before, the method used for task estimations is completely void of science, and thus, void of sense.

To make the estimations even more unreliable, the time allotted to estimate tasks is just some minutes.

However, it can be proven that the more time taken to study a task, the more reliable the estimation is.

Every developer has experienced many times that tasks tend to be underestimated due to the fact that once you start implementing them, new information about the task emerges, which would completely skew the original estimate. This is just a natural occurrence: certain constraints can simply not be known before the actual work on the task begins.

A better approach is to assign the task to a developer or two, ask them for a rough time estimation, and also ask them to revise it again whenever they deem it necessary.

In any case, in Scrum, these unreliable task estimations form the basis of the ‘Sprint’ goals, which are thus themselves unreliable goals, but which will nonetheless be used to measure the capacity of the team.

Fallacy 4: Estimating Capacity instead of Calculating it with 100% Accuracy

Why would any data that is readily available require estimation?

Measuring the capacity of a team is extremely easy. It requires:

• count the number of developers
• multiply this number by the number of working hours they have in a week
• subtract any unavailable hours such meetings, vacation leave, etc.

The result is the actual capacity of the team in man-hours, with 100% accuracy.

The Scrum model however professes to take the number of ‘story points’ completed in previous ‘Sprints’ and use this as a measure of capacity, and rename it as ‘velocity’ (because buzzwords do sell).

This model is flawed for the following reasons:

• The method used to estimate the duration of the tasks is unscientific and thus unreliable;
• Scrum assumes that with every ‘Sprint’ the ability to estimate tasks using ‘story points’ improves, and thus the ‘velocity’ becomes more reliable. However, with a ‘Sprint’ duration of two weeks, the number of ‘velocity’ measurements in a long period as six months is only 13, which is statistically insignificant as a basis to average out the ‘velocity’ of the team, especially when considering the number of inaccuracies and volatility that the model has;
• This model assumes that the denominator of the equation used to calculate ‘velocity’ is static: the ‘Sprint’ duration. But not every calendar period is the same. Developers might be on vacation or sick leave, an urgent task might get in the way, and so on. Thus, one ‘Sprint’ is most often not equal to another.

Fallacy 5: The claim that “Without Trust in the Team, Scrum cannot Work”

As a start, Scrum cannot be proven to work, with or without trust in the team.

In any case why wouldn’t a team of capable developers focused on their tasks but not trusting each other be incapable of meeting the ‘Sprint’ goals?

What kind of studies have been undertaken to prove this? Has someone managed to find and study a statistically representative number of Scrum teams that do not trust each other and arrive at this conclusion?

So why is the question of trust being brought into the equation?

The reason might be to make more room for ‘Agile Coaches’ who would be tasked with building trust within the team. And how does one become an ‘Agile Coach’?

Well here comes the money train again, its by obtaining another two-day certification called ‘Agile Coach’, usually conveniently sold by the same companies that sell the ‘Scrum Master’ two-day certificate, which say that ‘trust’ is a requirement. Some food for thought!

Fallacy 6: Are you sure it is legal in your country?

Since Scrum is unscientific, it is void of sense, and hence nonsense.

Now imagine an employee standing up and refusing to do nonsense. Can a company oblige such an employee to do Scrum?

Can companies oblige employees to do nonsense?