Nothing confuses new Agile teams more than story points. There’s this blank look that comes over people, often followed by frustration when the methodology doesn’t become immediately clear. What’s funny, is that it's actually the simplicity that causes this confusion.

In Agile terminology, we often refer to a task or collection of tasks as a ‘user story’ and it may sound something like this:“As a visitor to the website, I want to be able to share an article on my social media profile so that my friends and colleagues can benefit from the insight available.”See what I did there? Anyway. A user story encapsulates the desired outcome for the customer and can then be broken down into some actionable tasks e.g. add social sharing buttons to the page, test it out etc.Story points refer to the effort required to complete the story. Simple enough, right?You’re still probably thinking ‘how do I use them?’ or maybe even ‘what value do they add?’No sweat - we’ve got 3 steps to get you up to speed with story points. Your attitude towards planning will never be the same again...

1. Story points are a measure of EFFORT

As human beings, we reference ‘new’ things relative to other things which we already understand. For example; if I began to describe a new transportation device with four wheels and an engine you would immediately picture a car. It’s just a natural response.When we talk about story points for the first time, the natural response is to think ‘time estimation’ - because that’s what we do by default.“Hey Jim, how long do you reckon that job will take?”“I’m thinking 3-4 days, Bill”Sound familiar? How often does it turn out to be 3.5 days exactly? Maybe you can get close if it’s a task you’ve performed a hundred times... But when we work on complex products and projects - many tasks are new and unknown.The problem is, human beings are absolutely terrible at giving time estimates. We’re subject to forces like focus bias (only going off the information we’re given there and then) and people-pleasing (I don’t want my boss to hate me, so let’s be optimistic) amongst many others. Generally, we’re just not good at giving accurate time estimates to a range of tasks.A story point is simply a measure of effort. You might factor in a combination of difficulty, complexity, dependencies, time and anything else that could contribute to ‘effort’. Furthermore, it’s your measure of effort and no-one else's.

2. Relative estimation

We estimate tasks relative to each other and assign story points as a result.The most common system for using Story Points is through the use of a Fibonacci sequence. It’s a sequence noticed throughout the natural world (often referred to as the golden ratio) and is simply the sum of the previous two numbers in the sequence. Here it is:0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...(Here’s the maths for those of you that are into that kinda thing: Fn = Fn-1+ Fn-2 )Below is a visual representation of the Fibonacci sequence:

The reason we love using Fibonacci to estimate effort (instead of a linear scale e.g. 1-10) is that it forces you to give a relative estimate rather than agonising over a specific estimate. It’s easier to ask if the task is a 5 or an 8, than asking if it’s a 5, 6, 7 or 8…So in practice - let’s say you have a product to deliver, with a handful of ‘tasks’ that need completing in order to deliver this product:First, we’d call those tasks ‘user stories’ and make sure we understand how that task adds value, then we’d rank them from least effort to most effort.Now we look at the smallest task and assign it 1 story point. Then move to the next and ask whether it’s the same effort as the previous task, or does it require a greater number of story points? If greater effort, we give it a 2 and continue until all the tasks have story points.In case it’s not obvious - it’s critical that the people doing the work are the ones that do the task sizing. And, if you reach a task with 21 story points or more, many teams would argue that task needs to be broken down into more manageable chunks.

That’s it! You’ve now got a backlog of tasks that are accurately estimated.Still need convincing about the accuracy bit? Try this:Ask your team to guess the distance, in miles, from London to Rome. Make sure they write their guess in secret on a post-it, then only share once everyone else has written a guess. Note how wide the spread is!Then ask:"if London to Paris is a 2, now write down your estimate of London to Rome but using the Fibonnaci sequence"Finally, check the actual distance. No doubt the milage guesses are way off (plus hugely varied) but the estimation using Fibonacci is probably quite accurate.

3. Velocity

“Ok, my team and I are using story points to size tasks. Now what?”Glad you asked.Velocity, in its simplest form, is the speed at which something is moving relative to something else. If you’re driving your car at 20 m/s then the velocity of the car with respect to you driving it is 0 m/s. If you’re stood at the side of the road and someone else drives past at the same speed, then the velocity of the car relative to you is now 20 m/s. If another car overtakes that car at 30 m/s, then the velocity of the overtaking car is 10 m/s with respect to the first car.In Agile teams, we look at ‘Done’ story points in previous iterations and refer to this as our velocity. This gives us two main benefits:

1. We can look at story points ‘Done’ per iteration and use this information to help us plan for future iterations with more accuracy. If we can see a team averages 100 story points ‘Done’ in a two-week sprint, it would make no sense to plan for 200 points in the next sprint (over-capacity) nor would it be efficient to plan for 50 points (under-capacity).
2. You can take your teams' velocity data and use this to forecast future delivery dates of a larger product, or epic.

How? Let’s say your product can be broken down into 50 tasks. You estimate the size of these tasks using the Fibonacci sequence and give each task a number of story points.Let’s say this collection of tasks (or stories) has a total of 400 story points. Using the example above, let’s say your team has an average velocity of 100 story points per two-week sprint. Therefore, you could forecast the completion of this product will occur in 8 weeks (based on two-week sprints).The caveat here is that the team needs history to gather velocity data. New teams need a few iterations under their belt before they can provide any accurate forecasts. The challenge is explaining this to stakeholders, rather than being arm-twisted into committing to a delivery date. The choice is either a date plucked out of thin air now (that will almost certainly be wrong) or a date that’s supported by real team velocity data and will likely be very accurate.There you go - story points made simple.Your team can estimate tasks quicker and with more accuracy, they can ensure they are working to the right capacity and can even provide data-backed forecasts for future delivery dates.Let us know how you get on.Enjoyed this blog post? It is also available in our signature comic strip style for easy reading and sharing. View and download the pdf here.