One of the most shocking and at the same time obvious aspects of Scrum is the usage of Story Points to measure the effort to be done. It’s shocking because the teams usually are more familiar with time measures but, once one understands its nature, it’s one of the most obvious aspects of the Scrum methodology.

Time/Effort vs Time/Distance

In a classical fashion based on concepts like the Project Management Quality Triangle, the quality of a project has to be evaluated from three constraints:

So, if we want to deliver the best quality on a project because the quality is not negotiable, as one can infer from the agile manifesto, we must control those three constraints. Even though the scope and the cost are usually determined by the needs of whoever asked the project and his/hers budget, the time is usually something estimated by the somebody who will perform the effort. This will be a problem as the sooner the later somebody will ask for time estimations to the team in charge, and the development team is usually good making software but quite bad in futurology ;-). That’s one of the reasons why Scrum proposes to measure the effort, and calculate the time in basis of the team speed (aka. how much effort can be delivered in a chunk of time).

Even though we have units for the time (seconds, hours, weeks, etc) and for the costs (euros, dollars, bitcoins, etc), there is no clear unit for the effort. For some projects the effort could be “number-of-houses-to-build” but in the case of software development ones it is strongly hard to have a good unit. Luckily, Scrum proposes a really useful unit to measure the effort, the story points. This unit is quite tricky, as one needs to work a few before it is clear, but once it is correctly defined, it solves problems that can be considered superficial and some deep problems associated with the measure of effort.

At the end, and as stated by Mike Cohn in The main benefits of story points, the story points must be seen as the meters/yards of effort, once we understand them in this fashion, we’ll start to be deeply agile.

Main problems of estimating using effort instead of time

Obviously, estimating in basis of effort it’s not easy and from my point of view there is a couple of disadvantages about using story points:

• We need some background to have a way to measure story points. As stated in some articles (e.g.- Agile Estimation in 8 steps) it is really useful to do some iterations before we can measure Story Points properly this can impact the Product Owner plans, as initially the unit won’t be totally reliable.
• It’s difficult for the Product Owner  to understand them. Even more difficult if the Product Owner does not have technical background. They are a totally abstract unit and it’s not easy to understand what a Story Point means and how to manage it (and the expectations it generates).

Why we should embrace and love story points

On the other hand, there are several benefits which encourage us to totally adopt them, or at least give them a try. Furthermore I’ll add a couple of interesting (and non-obvious) facts about using Story Points:

• They drive the team to a better work analysis, as everybody in the team has to compare something deeply in order to give a clear proportion comparing with another piece of software.
• The conduct to proper roles assigned, the Product Owner can be responsible of timing and to better manage the stakeholders expectation. Meanwhile, the team can take control of effort, not time (as they do not manage resources). Finally, the Scrum Master can mix up everything using the speed, and agile can flow smoothly.