Story Points to Hours — The Best Estimation Approach

To best grasp the concept of story points, let’s go back to the fundamentals. Any project is a problem-set from the engineer’s point of view. To solve it, an engineer will break it down into smaller problems. They might not know how much time exactly it will take to solve each problem, but it will be no trouble for an engineer to say which problem is harder or more complex. This is how story points made their way into software development planning.

So, as a business owner, you hired a vendor who gave you a technical plan. You probably have several specialists to work on your project. You were talked to about the project’s scope, complexity and wiggle room for unpredictable work. The latter can be requirement changes, bug fixing, inconsistencies between the dependencies, etc. All of these are more of an abstract nature, talking about effort rather than hours. This is the exact reason it makes much more sense to estimate work in story points rather than in hours.

In this blog, we’ll answer:

• why not to call them ‘feature points’, ‘development points’, or ‘effort points’? What are these ‘stories’ at all?
• how does one translate story points to development hours?
• What is the best estimation approach?

Why story points?

So, as a business owner, you start with a meeting with your development team. In this meeting, the main task is to define the business requirements. This is the first and the most high-level requirements there are. BABOK or Business Analyst Body of Knowledge created a hierarchy of requirements for each level of project.

1. Highest level — The business comes with a set of goals or a business idea.
2. Then, depending on the methodology, the research is done to formulate stakeholder or user requirements.
3. After that, solution requirements are formed. They can be functional and non-functional. These requirements are turned into user stories.
4. Transition or implementation requirements are formulated along with the solution requirements. They are short-term requirements necessary to be fulfilled once and then they are no longer needed.

The picture below shows the hierarchy. The main point here is that only after going through a set of requirement definitions, it is possible to start estimating the work-to-be-done on the project.

Case-in-point

Imagine you are an offline vendor who sells awesome goods locally. But the local market is getting slow. So, going digital is usually the way to grow a business. Let’s formulate the business requirements:

• Grow revenues by 30% within 6 months after deployment of online platform;
• Reduce operational costs coming from order processing by 15% through digitalization.

Then generic the stakeholder/user requirements expressed:

• Stakeholder1 — Customer:

1. Ability to browse products and add them to the cart;
2. Ability to select delivery or store pickup with a discount;
3. Payment with card or cash in-store;

• Stakeholder2 — Store Staff:

1. Easy-to-use system for order management;
2. Integrated inventory management system;

These stakeholder/user requirements look a bit generic, but this is for a reason. They are not too exact because:

• Market and user research might not be finalized yet;
• More market data and feedback will come in over time;
• To avoid bias;
• Requirements will be evolving through iterations;
• And more.

The most interesting part for us is the solution requirements. This is where the user stories are developed. Plus, they should include acceptance criteria. So, we’ll take three of stakeholder/user requirements to showcase how to:

• turn them into user stories, with acceptance criteria
• and assign them story points.

What is a user story (with story points)?

Creating solution requirements and turning them into user stories with acceptance criteria is often the task of the technical product owner on the project. The picture below demonstrates the formula for user story + acceptance criteria.

Now, as a developer has a specific task with particular acceptance criteria, they can estimate.

Story points and the Fibonacci sequence

Story points are often selected from the numbers of the Fibonacci sequence. Fibonacci sequence is when each next number is the sum of the previous two.

1, 1, 2, 3, 5, 8, 13, 21, 34, 55 ….

And so on.

The idea from a developer’s perspective is the following:

• Story point 1 means a simple task, small in volume, without any dependencies, and generally easy. For example, creating one form field for newsletter signup.
• Story point 2 means as twice as hard as the previous task. It can be twice as many tasks or more complex tasks. For example, incorporating more validations on the input from the user, or input fields for email and for phone number etc.
• Story point 3 means three times as hard as story point 1 task. Or it might mean similar to story point 2 but with a dependency on some other task or API. For example, consider a full form with a variety of details.
• A number must belong to a particular state.
• We must validate that it’s an actual name and a valid phone number and not some gibberish. You won’t believe what users can type in!
• We must add select elements for country, city, etc.
• If it is a delivery address we might need to connect to some API that validates addresses for that country.

All in all, each next number from the Fibonacci sequence means that there is an increase in:

• Volume,
• Complexity,
• Dependency,
• Unpredictability.

Cae-in-point: Continue with the Example

Going back to our example, let’s create a few stories with acceptance criteria. Surely, these are simplified user stories. Also, you can also find more Acceptance criteria examples in our article.

Why did we assign points 3, 5, and 8 in our example?

User story 1 — product catalog — story points 3

Developing functionality for an online catalog requires:

• Fetching data from the API that stores product information;
• Designing the product catalog interface;
• Rendering the fetched data;
• Also, Might require logic for pagination, etc…
• And, of course, unit testing.

Even though it is a big task, it is pretty standard. It is a moderate volume of work, not complex. It is often seen as pretty straightforward. Even though there is a dependency, it is manageable. Lastly, there is very little unpredictability.

User story 2 — payment methods — story points 5

Generally, functionality for the payment processing includes:

• Frontend development for the interface,
• Backend integration with third-party payment gateways,
• Lots of testing for security and reliability.

This kind of work even though does not look like a lot, it is significant because it requires a lot of testing. The front-end/back-end/third-party services must be thoroughly tested for all kinds of user scenarios, transaction scenarios and conditions. This functionality deals with sensitive data so half of the work will be dedicated to ensuring the security of the payment process.

The complexity lies in the integration protocols, variety of scenarios, and thorough error handling. Also, consider declined payments or payment disputes. This development task is high in uncertainty and may include a degree of unpredictability.

User story 3 — inventory for the staff — story points 7

In short, the development work includes:

• Modifying the front-end interface to include stock availability, remove cart buttons, etc,
• Back-end development to ensure different views checking for the role of employee,
• Fetching and rendering stock data,
• Integration with an inventory management system.

Here, the biggest item is the integration with an inventory management system. There are potential challenges if the business owner might already have an inventory management system. So it requires an integration with the existing system and might come with limitations and integration complexities.

Plus, this user story has a dependency on the previously completed interface for the product catalog.

Moreover, with stock availability, we talk about real-time updates. The robustness of its implementation requires a lot of testing.

Lastly, this bit often is impacted by business processes. Hence, an added degree of unpredictability.

The story points to hours — the best approach

In our example, we got 16 story points total. But how to convert these story points to hours?

In our blog, we wrote about Software Development KPIs Startup should target. There, literally, the first KPI was Velocity. Each project manager and the development agency overall keep track of each individual developer’s velocity. They keep this data from project to project and measure it every sprint.

So, if developer John is responsible for user story 1 and his velocity is 9 hours per story point, then:

User story 1 = 3 story points.

3 story points times 9 hours equals 27 hours.

This is how much time we’ll expect John to take to complete user story 1.

Why is velocity the best conversion method?

You could think, but wait… Why there is no single way coming, say, from an industry standard? Or some exact rule?

For one, there are no pre-defined user stories. Undeniably, each custom development project is unique in its own way. It is also partly because each year the things you do with even one input field change and get more complex. Just compare the login form 10 years ago and now — the difference is staggering.

Secondly, the substantial reason is the evolving technology stack. The technology stack changes. Whether you develop a web app or a mobile app, the time required to do the same thing would be different.

Let’s take the same 3 user stories described above. If we develop a web application — it is usually a lower time estimate. If we develop these for a mobile app — it will be slightly higher. For example:

Lastly, the level of expertise. More experienced developers will do things faster. Generally, even from project to project, one can observe the velocity growth. In reality, more and more work gets done within the sprint.

Summary

• The best way to convert story points to development hours is by looking at an individual’s velocity over time.
• Take into consideration the technology stack and unique project requirements.
• What on the surface looks like one functionality can turn out to be extremely different if one analyzes all the requirements. Hence, different story points. From here, different development hours.