How to Estimate with Story Points

  • 4 minutes

Anastasiya V.

Project Manager

Viktoria K.


There are various ways to estimate app development projects. One way is by using so-called Story Points. While this type of estimation might not be the easiest, estimating with Story Points offers benefits to both app developers and clients.

The Story Points approach uses historical data to compare features of one project to features of a previous similar project to generate a precise estimate.

story points in agile

The gears in the image above are of different sizes and have unique attributes — just like features in a software development project. Imagine there were no way to measure the size of a circle. How could we determine the exact size of each gear? We could use Story Points!

Let’s walk through each step of the estimation process with Story Points.

Step 1 — Identify a Base Story

Story Points are a complex unit that includes three elements: risk, complexity and repetition.

agile development story points

To find our Base Story, we search for one elementary task that corresponds to internal standards of Definition of Done for User Stories and assign it one Story Point. This will be our Base Story.

Step 2 — Create a Matrix for Estimation

There are two types of scales used for creating estimation matrices: the linear scale (1,2,3,4,5,6,7…) and Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13 …).

Here at RubyGarage we use Fibonacci sequence numbers. We do this because people are really good at comparing sizes, but not at estimating absolute values such as number of hours. The difference between 1 and 2 can seem insignificant. However, the difference between 1 and 5 is obvious.

When estimating using Fibonacci sequence numbers, we create a matrix with rows for each sequence number and their associated stories. Then, we gather all our stories and start classifying them into rows, comparing the stories to each other and to other completed stories. Notice that our Base Story is already in this matrix in the first row with a value of one Story Point.

Here is one of our matrices:


Step 3 — Planning Poker

To assign Story Points to each story, we have a meeting where all specialists that will work on the project get together and play Planning Poker.

Planning Poker is a consensus-based estimation technique to estimate product backlogs. It can be used with various estimating units, but we use Planning Poker with Story Points.

planning poker agile

Here’s how it works:

Planning Poker Estimation Process

  1. Each estimator gets a set of cards;

  2. All estimators select backlog items, discuss features, and ask questions;

  3. When a feature has been fully discussed, each estimator privately (to make the estimate objective) chooses a card to represent his or her estimate;

  4. When all estimators have made their estimates, they reveal their cards at the same time. If all estimates match, estimators select another backlog item and repeat the same process. When estimates differ, the estimators discuss the issue to come to a consensus.

By the end of Planning Poker, we’ve filled out the whole matrix. Our tasks are divided into rows by the number of story points needed to implement them. Finally, we place each backlog item in the appropriate row. There can be several stories in one row.

what are story points

Step 4 — Planning the Sprint

Now that we have a size estimate, you may be wondering how we convert these sizes into man-hour estimates. Unfortunately, we can’t do this until the first sprint is completed. While the first sprint is in progress we can track the team’s velocity. As soon as the sprint is finished, we’ll know how many Story Points a team can complete per sprint. We use these numbers to forecast the team's performance for the next sprints.

When we have all backlog tasks estimated in terms of Story Points, we can understand how many sprints we’re going to need to complete the project. And finally, we can convert these abstract units into real calendar timelines.

RubyGarage estimates with Story Points because it’s quick and helps us understand the relative effort required for stories we’ve never faced before. Story Points help us provide our clients with more accurate estimates. Experience and reference points speak better than abstract man-hours.

Share article with

Comments (6)
to leave a comment
Поля Вълчева 11 days ago
The information is full and very helpful. Additionally, I have a question about the estimation of the story points. In case the User Story needs to be done from FrontEnd Developer and BackEnd Developer and each of them estimates with 8 and 4 story points respectively. How much should be the final story points? 8, Average of both or something else? Thank you in advance!
Anastasia Z. 10 days ago Поля Вълчева
Hi! Thanks for your question! It all depends on the feature that the team needs to develop. If there is a task that must be performed by different experts (Fronted and Backend developers), then each of them separately evaluates their part of the work.
David Durkee CSM 3 months ago
Good article and concise. There are typos in your first chart, "Step 1 - Identify a Base Story" The first column "Risks", the last point "Uncertainty in the..." is incomplete, unless your point was to be uncertain ;-D The third column, "Repetition - Monotonous tasks without any ricks and complexity" The fifth word in that quote should be "risks" not "ricks."
Maryna Z. 3 months ago David Durkee CSM
Wow, it seems like you've got eagle-eye! Thanks for your feedback. We'll review and fix the article once more...and once more ;)
Christian Kühnel 4 months ago
Hi, thanks for this good explanation. I have two questions: 1. How do you deal with stories that are smaller then the Base Story? 2. Do your stories include different tasks? Do you give points also for single tasks? Thanks in advance Christian
Viсtoria S. 4 months ago Christian Kühnel
Hi there! 1. We sometimes use 0.5 points for such tasks, where the 0.5 stands for an aggregate complexity which is less than 1 story point. In addition, when more than 20% of all tasks are estimated as less than 1 story point, we re-structure the scale and appoint a new tasks complexity level for a 1 story point task. Yet still, we try to choose a quite basic and simple task to represent a 1 point user story so that we’ll scale it up then, not down. 2. It all depends. A story can include tasks or sub-tasks, but we always opt for breaking the scope down in the way that one story equals one task. Still, when one story does include several sub-tasks, we tend to estimate all those separately for the sake of better visibility.

Subscribe via email and know it all first!