Story Points: Why we don’t plan in hours
We - as a human species - are lousy at estimating time and effort. Nobody has to feel bad now. It' s not our fault. Not really at least. Instead, we can blame it on the planning fallacy , a fallacy in our thinking that causes us to approach planning too positively.
While this fallacy is all too well-known, many companies and teams still plan their tasks with a fixed number of hours. This leads to rigid planning constructs and deadlines that are difficult to adhere to. Most of the time you're over it. Sometimes below. Neither is optimal for proper planning. A method used in Agile Software Development can help: Story Points .
Agile Software Development is an approach to project management that doesn't plan everything in advance. Instead, there are short planning cycles, early prototypes, and the possibility to change things as it makes sense. Story points fit perfectly into this way of thinking.
They're able to replace planning with time in project management. They provide more flexibility and contain more information than a mere time entry. In addition to the effort, the points also reflect the complexity of each task and how much risk or uncertainty it represents.
In the beginning this might seem odd, but the advantages soon become apparent. An example: The team has to integrate a function into the current product. Nobody is experienced in this, but it should work quickly. Because of the uncertainty, the task gets 8 Story Points. In the next sprint, the feature is to appear in another product. This time there will only be 5 Story Points, because the uncertainty has decreased.
Story Points offer more advantages than just more information. Among other things, they effectively combat the Planning Fallacy. In return, they get support from the Fibonacci Sequence in which the Story Points are arranged. Instead of simply counting 1,2,3,...,9,10 Story Points usually count 1,2,3,5,8,13,21, ... This has the advantage that the distances between the higher numbers become larger and more visible. The difference between 8 and 13 is bigger than between 6 and 7.
In addition, the points are not simply awarded by the project management, but are traditionally created during discussions. The whole team sits together and determines them together during "Planning Poker".
Everyone's got a set of cards with the values of the Fibonacci sequence and estimates concealed how many Story Points they would give a task. At command, they will all reveal their card. Afterwards, the conversation usually determines how many points a task should receive. There are no averages, only consensus. The whole team should agree.
Also, not one person should decide on the points alone, just because they may know the most about them. The idea of Story Points is that everyone can put in their two-penny worth to discover problems early on. In other words: design, development and marketing also estimate each other's tasks. Because even if too many cooks can spoil the broth, six eyes see more than two.
You should also keep your fingers off the value during a sprint. If you misjudged and the Story Points should actually be lower or higher, you shouldn't change the value. After all, you can learn from the miscalculation in the future.
They’re not for everything
Finally, not everything needs Story Points. A Facebook posting doesn't need any points if you know how long it will take to write it. The same applies for brief research, meetings and the like. Time blocks work just as well or even better in these cases. And also tasks you can't complete - for example community management - don't deserve Story Points.
You shouldn't be deceived either, by the way. Just because Story Points originate in software development really doesn't mean they're not suitable for other areas. Management, marketing, design and can also profit from them. After all, the people in these areas are no better at estimating than others.
We've been working with Story Points for a while now and benefit from the more flexible planning. Do you want to profit from them too?