What’s the Point?

Don’t worry, I haven’t fallen into a deep pit of philosophical Agile despair (yet). What I’m about to do is shed some light on something we use on a regular basis while practicing Scrum that we rarely think about. I’m talking about Story Points, which we use to estimate our User Stories.

Estimation? We all do it.

Of the various estimating methods out there, Story Points are one of the most used. Teams choose the numbers of the Fibonacci sequence to individually mark Product Backlog Items. In doing so, they get a rough idea of the effort each item may require when put into development. This is being done regularly during Refinements or Sprint Plannings, and it helps the whole team understand the amount of work ahead.

But do all teams know how to use them correctly? And what is really hiding under said effort?

What’s it made of?

We talk about the effort developers need to put into Product Backlog items to finish them successfully. But they may imagine very different things when they are asked to translate that effort into Story Points during Estimation. If you’re a Scrum Master, you need to find out whether your developers are on the same page.

To properly estimate the effort, your team needs to consider several things.

The amount of work to do

Are you going to develop an application that returns one line of text or one hundred lines of text? The first task is quite simple and isn’t that demanding. The second task looks more difficult, but is it really? Once you figure out the first line, you can replicate the process to some extent and your jobs gets much easier. Yes, the effort is higher, but not by that much.


Now imagine your application must not only return lines of text, but also be able to edit them and send them to other applications. In this case, the effort will be much higher, right? Complexity affects effort immensely. The more functionality you’re getting, the more work goes into developing. Complexity must be taken into consideration when estimating your Product Backlog Items.

Risk and uncertainty

In an ideal world, this wouldn’t be an issue. Everything would be crystal clear and done without hesitation. Unfortunately, we must be real and admit there is always some level of risk and uncertainty. For example, the original request might not be described perfectly, feedback from the stakeholder wasn’t coherent or the code you’ll be modifying is old and not well documented. When estimating a Product Backlog Item, these elements must be taken into account.

Takes all three to tango

These three components create the effort that we want to specify as much as possible. By explaining them to your team, you’ll get everybody on the same page, you will be able to discuss all three factors during Refinements and your estimates will get better and more consistent over time. This is not an exact science and never will be, but by thoroughly exploring everything that goes into estimations, we can certainly get closer.


This article was inspired by https://www.mountaingoatsoftware.com/blog/what-are-story-points.

You may also like:

What’s on the Agenda? (Part III)

Hello again, The third part of the Agenda is here. Last time, we talked about reviewing User Stories from the Product Backlog and clarifying them…

What’s on the Agenda? (Part II)

In our previous article, we guided you through the first two points of the Planning Agenda. We described reviewing User Stories from the Product Backlog…

What’s on the Agenda? (Part I)

We explained what Planning in ScrumOne is in a previous article. We also mentioned that is has an agenda. Every meeting has different rules and…