The mythical story point
Posted on Feb 13, 2020
Blue cheese of software development. Beloved and hated. That’s what story points are. Some teams find them extremely useful, some teams think they are waste of time and effort. The only way to find out if they fit into your teamwork is to give them a proper try. If you don’t like them, no-one prevents you to manage your work estimates with other available techniques. But at least give them a chance.
Story points measure the relative complexity of the story and it’s always defined by developers - not by managers, scrum masters nor product owners. Relative complexity is as straightforward as it sounds: If a story takes 5 story points and other takes 10 story points, it means that the latter is relatively twice as complex as the first one. Only relative amounts matter.
Story with same complexity, thus same amount of the story points, might take different times to develop. This is because of the available tools, skills, seniority of the developers and so on. That’s why story points are in a core principle already measuring totally different thing than for example ideal days.
Where does this figure help you? The most common answer is sprint planning where team decides which stories they can allocate to a sprint. But that’s only small part of the truth:
- Prioritisation. If product owner sees an item with large amount of story points on top of the product backlog, he or she probably wants to split the activity into smaller pieces or simply prioritise smaller items on top.
- Knowledge sharing. Concept of the story point is based on collaboration - typically points are defined by a team of developers, not just an individual person. Team gathers in a planning poker or estimation event and shares the most current information relating to top stories.
- Validation of readiness. If developers are able to say how complex the story is, it also means that story is probably almost ready for development. Story points can become your gatekeeper: Only estimated stories are prepared well enough for a sprint.
- Resource planning. We know approximately how many story points our team can burn within a sprint. We also know approximately how many story points we have on our product backlog for the next release. It’s a clear signal for resource planning.
Of course you can do many of those with any other estimation technique, such as ideal days. But story points actually encourage the team to solve problems and decrease complexity instead of work against hours. It’s a bit similar comparison as piece rate vs. hourly pay - the first one is driven by results and the latter by deadline. Result-driven thinking is what you gain if you are able to implement story points properly.