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.

Consulting, coaching and interim management

Looking for an interim CTO to steer your software business to the next level? Or would you like to expand your team's knowhow with coaching or background research? I provide remote consulting to global software companies from US East Coast, UK, Central Europe and Nordics.


I’m an experienced entrepreneur and investor with a rapidly growing track record in SaaS, blockchains and decentralized applications. With over 20 years of work experience in software business I help companies to build better technology strategies, accelerate innovative development and drive product-led growth. My passion is to steer tech enterprises to create new innovations that are changing the way we work and live.

I write about software startups, Web3 and blockchain concepts. Join to receive these blog posts and occasional announcements via email: