Tuesday 7 March 2017

Why the heck do we need story points? At least several reasons why every team member should care.

Imagine a development team, working on a mobile solution that was supposed to be delivered in five months. Even though deadline was clear, the decision was made that the team will not be bothered with estimations. The backlog contained five big themes, out of which four were major from the perspective of business value. In the beginning, work was progressing well. Two major themes were finalised in first two months. Third major theme, however, turned out to contain unexpected complexity in few turns, and took almost three months of development. Even though it was pretty soon clear that there is a high risk that project deadline wouldn't be met, it was too late to change the approach. The project was delivered end of fifth month, containing only features that were completed at that point. This had a huge impact on users, and majority of them gave up and switched to usage of a similar solution already available on the market. If the product owner had known that the third theme required so much effort, he would have probably prioritised list of user stories differently.

How would you feel if you were member of this team? Probably the worst feeling of anyone working on a software solution is if software is in the end not used by anyone.

What can be the possible reasons for end results not being used? There are of course many, but one of the common ones is described in the story above - prioritisation not being performed well on a project with deadline. Prioritisation is done by product owner and is influenced both by business value of an item, and its cost. The cost itself is calculated based on the estimation.

So here we are. Story points determine cost, and cost highly influences prioritisation. And prioritisation will determine if software is serving its purpose and end users, and therefore to which extent it’ll be used.


Besides that, majority of projects can never be initiated in the first place and executed later on without at least rough cost calculations. When I try to explain this to people I always compare it to over simplified example of buying a pair of shoes. No-one is usually going to buy a pair of shoes without seeing how they look, checking if they are comfortable and looking at the price (assuming we are in a physical store and can take them out of the shop immediately after payment). If customers would not be able to know these things, shoes manufacturing and market as we know it today would not exist, so as many interesting professions in this industry.

So talking about software development projects, estimations are needed just from the completely practical reason that project cost money, so as shoes and anything else in this world (except from love and friendship of course :)), and someone (for example customer) needs to know the price and to pay for it. Project costs are calculated by long term planning, and one of the most important inputs for long term planning is backlog estimation. As project progresses, backlog estimation is occasionally revisited. Over the time it becomes more and more accurate because team gets more mature, and highly valuable historical velocity data is being gained.


Furthermore, analysis and discussion about required effort for implementation of backlog items can reveal complexity or risks that were unknown before estimation was performed. Revealed dark corners of the project can lead to conclusions, valuable for in-time architectural or design decisions.


All above is related to agile estimations in general. Talking specifically about measures, the most common ones are story points, ideal hours and hours. There are so many resources where you can find out about advantages and disadvantages of each. My personal preference is story points. The main reason is that units are relative and therefore last longer. In addition, estimation process is faster. Somehow it is always easier for people to pick up the value from a scale than to estimate required effort in hours. The last but not the least, poker planning sessions and story points usage can actually be fun. I’ve been on some very valuable and at the same time fun poker planning sessions.


Sometimes it happens that people know they need to estimate stories, but reasons for this are unclear, so naturally they do not care. Understanding the background will lead to communication rise and increase of engagement. What are your thoughts on this?