The mythical story point

Posted on June 28th, 2018

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.

Leading a development team or SaaS startup?

Would you like to boost your team's productivity with process improvements, new tools or agile management? You can hire me online for interim management and coaching. I provide remote consulting to companies mainly from US East Coast, UK, Central Europe and Nordics having outsourced teams across the world.
Profile  |  Services  |  Customers  |  Pricing

comments powered by Disqus
K. Tanninen

I'm an Interim Manager, Agile Coach and SaaS Founder. With 20 years of work experience I help global software businesses and distributed teams to perform better.

I write about team leading, software development and SaaS startups. Join to receive these blog posts and occational announcements via email: