1, 2, 3, 5, 8, 13, 21. Anyone who has been doing any sort of Agile Software Development will immediately recognise this number pattern. It’s the Fibonacci sequence, which are used as points to size up user stories. Never did my high-school-self think I would ever meet my old buddy Fibonacci ever again and yet here we are.

Story points are an important metric that helps with the estimation of a project’s timeline and budget. Notice I said, “helps with the estimation”, not, “enables us to accurately determine”. Point being- it’s impossible to determine the time or cost a story will take with 100% accuracy because there are many dependencies, many of which are out of your control. There’s no fail proof formula you can use. So if you know of a method, drop me a note and let’s make a tonne of money together!

______________

If you know of a method, drop me a note and let’s make a tonne of money together!

What’s wrong with estimating hours?

We use story points rather than the number of hours because when developers look at a task, they find it much easier to tell you how complex it is, as opposed to how many hours it would take to complete.

There are a number of systems used today to size up a story- t-shirt sizes (XS, S, M, L, XL), 2n (1, 2, 4, 8, 16, 32), etc. Keep in mind, what matters is not the sizing system you use, but the size of the story in relation to the other stories.

Story Points Example

In the example above you can see that all these companies use different sizing methods, but their relative sizes are the same- that’s key to an accurate estimate!

How do I determine how many points a story should be?

First of all, know that it is the job of the developer, not the product owner, Scrum Master or stakeholder, to perform this estimation. Although, these other players may and should provide their inputs, the final decision should be left with the person who is doing the work.

When developers look at a story, they should consider 3 things:

1. Risk / Unknowns

Unknowns can be from the developer’s side, where they will need to ask questions like:

“Have I done this before?”

“Do I have experience in this area?”

“How familiar am I with this system / gem / library / SDK?”

Unknowns can also come from the client side. Is the requirement crystal clear? Is the Product Owner able to describe exactly what they want and are they able to answer all your questions? If not, then more points need to be assigned to this story as it will likely take more time to research or make changes.

Once, we had a story called “A user can checkout their cart”. The Product Owner had not thought of what the checkout process should look like. Should it show a summary page? Should there be a payment confirmation page? Additionally, we were instructed to use a payment gateway we had never integrated with before because their rates were better. We estimated it as 21 points to his horror. But with a bit of coaching, he began to see that the unconfirmed specifics of the story and the decision to try a new payment gateway posed a high risk and hence deserved more points.

2. Time

Understandably, the larger the feature, the more time it will take and the more points it deserves. How big is the task? How much effort does it require? How many resources are required to work on this? Although a story may not be complex, it doesn’t necessarily mean it should be assigned few points.

“A user should be onboarded with a wizard”, was a story we had to tackle for a InsurTech startup. There were few unknowns; the task was simple and straightforward; the client knew exactly what they wanted; and the designs were ready. It ended up being a 13 point card. Why so many points? There were 8 screens in the wizard, 2 of which were conditional, with 1 or 2 questions on each screen depending on what the user answered.

Simple? Yes.

Clear? Yes.

Time consuming? Also yes. Hence, the 13 points.

3. Complexity

How difficult is the feature? What do the algorithms looks like? Are any special skills or experience required? Are there many exceptions to the rules?

We had a client from a freight shipping company who wanted to build a Rate Management System that could accept cargo dimensions & weights and ports of departure and arrival and produce a quotation. The algorithms they gave us were in 7 excel files with about 5 sheets in each! It was a black hole of numbers, if, else’s, formulas and exceptions.

The client knew what they wanted and they had been using these Excel sheets for years. So there was little risk of the algorithms being wrong or changing much, and they could answer every question we had. But because of the sheer complexity of the task, right out the gate, we said, “21 points”.

How do I translate points into time & cost?

So you’ve now got a backlog with stories and they’ve all got point values assigned. Now what? Unless you want to be paid in brownie points, you’re going to have to translate these points into time and money.

On average our developers complete 10 points per week, or 2 points per day. This makes the math easy as you simply divide the points by 2 and you get the number of days it will likely take to complete the story. Multiply that by whatever your charge rate is, and voila, you have your time and cost estimation.

Find an algorithm that works for you and your team that converts, as accurately as possible, points into time. Learn and adapt if you find your estimates are too low or too high against the actual time taken to complete the task.

______________

Points estimation is an informed decision that can be made with a degree of accuracy that improves with experience

As you can see, although points estimation is not an exact science, it’s far from the truth to say that it’s a shot in the dark. Points estimation is an informed decision that can be made with a degree of accuracy that improves with experience. The more projects you work on and the longer you work together with your team, the more you’ll be able to understand and gauge how long is needed to complete the stories. So go ahead, pick your preferred sizing system; estimate stories based on complexity, time and risk; learn and adapt; and reach a stage where you are consistently delivering projects on time and on budget. This will be highly appreciated by your clients.