Of what are User Story Points made of?

From time to time, in every project, before and during development, it arrives the moment we need to give some estimates on the work we are going to do. The client want them, your company want them, your Product Owner ask for them, and all of them want them for different reasons, and the use they do with them it’s not always reasonable or consistent.

There is a long time open debate about estimates, I will not discuss how estimates must be used in order to be used in a meaningful way, but it’s clear, especially for development team, how they are often far from reality.

I will just say there are good ways to estimate, it should be and iterative and incremental process, you assign estimates to those items that still don’t have one and correct those with fresh and newly information, and some teams are better than other in this operation.

For those using SCRUM and writing PBI as User Story they are probably giving estimates using Story Point. While estimates using planning poker is straightforward, giving estimates even using Story Point will bring some vivacity when discussing how big a User Story should be. At least at the beginning.

So I found useful define what a Story Point should be made of.


Story Points

Story Points is a technique to give a relative and adapting time varying measure of effort needed to accomplish the delivery of a increment of product.

Usually are represented by using a pseudo-Fibonacci serie (0.5,1,2,3,5,8,13,20,…) or the exponential function (1,2,4,8,16…). There’s even who uses T-Shirt sizes (xs, s, m, l…). You can use whatever you want, even build your own scale of values. The advantage are the ease of use and the semantical abstraction from working hours.

The reason why we are not using any available number we keep in mind is that we are trying to do our best in sizing something that is uncertain. When measuring uncertainty we are good at just giving an order of size of what we are measuring, so it’s better to compare each element starting from something smallest and accurate, fully covered and understood, and proceed with others keeping in mind the first.

Science demonstrated how toddlers have an innate numerical intelligence that give them the ability to work with the quantitative aspect of life, understand it and give an estimate.

Starting from the first months a child can elaborate concepts of “few” and “many”. Next coming months he can elaborate one, few, many, until he can count.

Let’s for example think how tall a person could be. It’s quite an easy task with someone standing close in front of us, because we can evaluate him against us. We can easily evaluate if another person beside him is taller or not and how much with quite good precision.

It becomes more difficult if the person is standing some meters far from us, or even worst if he’s standing far in the middle of a desert where we cannot compare him with nothing.

We are not estimating the number of balls of a playground balls, we are estimating something that still don’t exist, that will be certain only after we did it.

That’s why we don’t even care too much high value, because the bigger the User Story the bigger the uncertainty is.

So, we use Story Points to approximate the size of effort of something that is in the complex sphere and we really don’t know how exactly big will be (and we even shouldn’t care giving an exact value).

Good or bad, Story Points are mostly bad and harmful for teams and companies that use them in a bad way or struggle too much on the correctness of some values coming from a planning poker.

Before arguing about bad or wrong values we should find a document defining correctness of user story point.

Let’s dive in.

When you estimate using Story Points do you just consider the amount of work to do?

Often I see developer teams during estimate session just considering how big a User Story is based upon the merely number of things to do.

“We need to create one or two classes, design that component”

“we will write down some functions and we are done”

“change a little that component, touch another…”

Enumerating the amount of things to do is a start and is easy, but what’s the whole made of we should care instead?

Mike Cohn gave us an advice and said we should consider two other dimensions when estimating using Story Points.

One is the complexity of work

Even for easy tasks complexity must be accounted.

If I have a web form with one field estimated 1 point big, we need to ask if ten fields, with interactions between them, will simply takes ten times 1 point, less or even more, because It’s not said complexity will be linear.

The other is the level of uncertainty

Something untold or unclear will make the Dev Team asking for more detail to the Product Owner.

If that Item will remain still unclear its status will not change from not-workable to workable, meaning that it cannot be moved inside the next sprint.

Working on legacy, and hence untrusted code, is a very risky job and will contribute to raise the risk of uncertainty about the implementation of the story.

Developer team must consider that and trust their feelings or follow their needs.

There are a lot of definitions about what “legacy code” is; old but working code, creepy code, not safe, unmaintained, need to refactor or not tested code. Whatever. all of them are valid. Just pick one or more It doesn’t matter..

I want to add another dimension useful to an agile team.

The amount of refactor

Developers mentally simulates the flow of changes that will be made, and figure out they will pass through some components that need to be refactored now, before it’s too late.

Never wait. You must take care of that.

Beware just to refactor the minimum bare, or to clarify, just what you really need to touch in order to implement that feature and accomplish to your task. Do not refactor more.

Things to put inside Story Points

So concluding, next time you will estimate using Story Points don’t be afraid to always consider:

  • The amount of work to do
  • The complexity of the work
  • Any risk or uncertainty in doing the work
  • The amount of refactor

Putting all those aspects inside final value of each User Story I’ve seen could open a debate.

But why, what’s the problem with that? There’s no real reason why for example a Product Owner should frowning about that.

Story Point is a relative and adapting time varying measure of effort and they are just useful for internal use only, in order to schedule the work to do. Even worse some companies would like to use them across teams in order to gain consistency and make pointless assumptions and then take bad directions.

There is no real profitable usage of Story Points outside the team.

Remember moreover that sooner in software development is better than faster, and that to go faster you need to slow down and take the necessary time to do your job well.

We struggle so much on “wasting” time giving estimates knowing that are useful just if used in the right way, they are obsolete in the moment we go out of the meeting room, and we also know they are simply always ever and ever wrong in a small or big amount.

So estimates with care, but don’t care too much estimates.