Objective Story Points

5 min readSep 16, 2021

The key to the Planning Fallacy is that as humans we tend to estimate our tasks as taking far less time that said tasks will actually take. For the most part, people tend to be more optimistic in their estimates in everything they do, not just projects. — Michael La Pean (1)

Developers who try to estimate how many hours of work a given task takes often discover that they underestimate the duration of the task by a factor of 2 or 3, this is more true for estimating more complex tasks. Maybe our egos tells us we are much more capable than we really are, so called “optimism bias”. Software development isn’t like brick laying - each bit of new code may be an entirely novel invention so we can’t rely on experience to estimate how long it will take, in any case developers differ in their levels of experience and ability.

So having had these bad experiences with estimating absolute time taken, in agile development we use Story Points, and these reflect the relative complexity of a story - complexity is much easier to asses.

Typically the Fibonacci Sequence is used to categorize Story Points into discrete complexity scores and then the team vote on which category of points to assign the story. The complexity scores should reflect the degree of components, interactions and uncertainty around the story and have fairly objective definitions — you should define and agree these. When there is uncertainty you should refine that out but where you can’t then increase the score.

1SP — task can be entirely described in 1 or 2 paragraphs and is easily performed in a few hours or less
2SP — task as above but might require 1 or 2 days
3SP — task involves a few components with simple interactions
5SP — task involves a few components with complex interactions
8SP — task involves many components and interactions
13SP — task involves many components and complex interactions

But here again, developers may not be very objective about these categories and just rely on gut feeling - how long a story takes can’t really be decided by popular opinion. I have even worked in so called “agile” teams where people are equating 1 story point to 1 day. This is just wrapping the planning fallacy in agile lingo, and it fails. I have also worked on teams where story points are voted on and sprint after sprint ends with stories that didn’t even get started, the planning problem manifests once again.

If you are doing fine with whatever methods you are using, then the adage of “if it ain’t broke, don’t fix it” applies and you can pat yourself on the back and put aside what I’m about to say for another day. But if not, then lets have a deeper look at these issues and see how I resolved them and got our burn downs to be smooth and sprints end with all stories complete, time after time.

In typical organizations, most decisions are made either autocratically, by a top-down leader, or democratically, where everyone shares their opinions and those opinions that have the most support are implemented. Both systems produce inferior decision making. — Ray Dalio (2)

Taking a vote on the story points can reproduce the same problem as estimating time taken. Each person brings their own subjective experience, and opinions to bias the estimate, yet they may not be the person who finally ends up developing the code - how much are they invested in getting the estimate real? What we should do is be objective about the complexity and base it on a tally, instead of a guess.

Kruger and Evans (2004) suggest that the simple act of unpacking projects into their constituent deliverables and tasks highlights the true size of the work involved and reduces the planning fallacy. — Werner Meyer (3)

In my preceding article How to keep your scrum agile, we learnt that a User Story should be the smallest description of behavior that it makes sense to a user. During refinement we should keep digesting the User Story until we have a number of production level stories each describing a behavior at the technical level. The amount of acceptance criteria for testing will typically be a good indicator of story complexity - if it is not, something may be wrong. These production ready stories should be broken down into tasks. Once we have that, we have something to tally up to get our objective story points.

Once we have broken a few stories down into tasks, we can create task categories and further split these into trivial, small, medium and large - that is categories most developers can agree upon objectively. This can then be expressed in a table that can be used as a reckoner for estimating the total story points, see table below.

Of course you will need to produce your own table with relevant tasks and complexity points for your development needs, adding more rows to make it real for your case as the above table is incomplete. A typical production story may check a number of boxes on the reckoner to make up its tally, but it should not be very many. If you end up ticking a lot of boxes, you may have failed to refine thoroughly.

It ought to also be obvious at this stage that we are going to have higher story point estimates than we would get just guessing 1, 2, 3, 5, 8, 13, 21 etc., so we have much higher resolution - this can only be good. It may be that only having 7 or so complexity categories is not enough to describe the practical reality of our development tasks? In practice we found that 1 regular SP equalled 4 objective SPs.

We now have a much more objective measure, and the team can align on a set of agreed standards and so should not need to spend time with story point voting. Of course, this approach will also require the discipline to properly refine the User Stories and realistically elaborate the tasks, but ideally your POs will be able to provide minimal stories that are easy to estimate to begin with.

Objective Story Points

Written by John Coleman