Blog / Tech / Agile

Agile Development 101 – Story Points Estimation

  • Rating — 4.5 (6 votes)
  • by Tony
  • Updated on June 10, 2020
  • Read —
    7-8 minutes
story points

Frankly speaking, humans are really bad at making estimates. Especially, absolute estimates. Which is why estimation is often called an Art of Guessing. Fortunately, agile story points are here to fix this.

  1. Relative VS Absolute Estimations
  2. What is a User Story in Agile?
  3. What is a Story Point in Agile?
  4. How to Calculate Story Points in Agile
  5. Agile Story Points Fibonacci Sequence
  6. How to Get Better Estimation of Story Points with Planning Poker
  7. How to Convert Points to Time

Relative VS Absolute Estimations

4-buildings-with-relative-markers-stairclimber-exampleYou might notice that humans are bad at making absolute estimations. But it’s much easier for us to compare things. Just test yourself! Take a second and make a guess at how big your computer screen is. Is it hard?

Now, try to guess how much bigger your screen size compared to the keyboard. You probably guessed “2x times bigger” in a blink of an eye. Take notice how much easier it was to guess size while comparing things.

Making an estimation in the Agile way that helps us to overcome human nature and take advantage of out “comparing” skill.

  1. Agile keeps things simple.
  2. Story Points help estimate projects RELATIVELY.


What really makes agile estimation work is sizing stories relatively.

Keeping things simple means assigning one number to the bigness of the story point. You divide your project by user stories, not development phases like analysis, testing, development, delivery, etc. There are no separate development stages in an agile project, there is one number for one story, that wraps everything necessary to make the story work.

What is a User Story in Agile?

A user story captures product requirements from the perspective of the client. It is a minimal use case scenario that should be performed by the program so the user gets the result. Which is why every user story should contain:

  1. Role (client / business owner / admin / institution).
  2. Goal (login / get result / visualise data / feedback).
  3. Benefit (Expected outcome).
  4. Description.
  5. Acceptance Criteria (transaction is performed / user data is stored).

These ingredients are obligatory to any user story. Based on those criteria development team can propose all those tiny requirements that should be performed, in order to make the story work.

Now let’s get back to the user story points in agile.

What is a Story Point in Agile?

Unlike the specific measurement of time, such as a man hour or developer day, story points are abstracts. These units of measure represent relative whole team effort but keep time out of the equation. You can even give points another naming.

Popular Names for Story Points:

  • Points.
  • Gummi Bears.
  • Foot-Pounds.
  • NUTs (Nebulous Units of Time).

A story point is a unit of the collective team effort.

We keep time out of it because lots of things affect how long something takes, including interruptions. It is useful to assess efforts separately from these other influences on duration.

Do you want an incredible idea bring to life?

Thanks to this “abstract” thinking, we can push our team to make relative estimations without getting into details. It will help us compare such different tasks like “Facebook login” and “Like button”.

Story points also help us with mid-range and long-range planning. It’s not about focusing on what will happen this afternoon, but instead of what may happen further down the road. Thus they prevent premature commitments.

In addition, such abstract thinking also gives way to the creativity, and software development is a creative process. We make things out of nothing.

How to Calculate Story Points in Agile

.point based estimation

Now when you get the idea of points, we’ll proceed to actual story points estimation in the agile way. Make a stack of all story cards you need for your project (FB login, like button, share button, live feed, etc). Find the story card that you think is the easiest to do.

Then gather the team and let it review the mockups, wireframes, requirements (role, goal, description, acceptance criteria). The team will ask clarifying questions and makes a walkthrough of user story with the client. The team should apply a number of point for it. For example 1 points.

Once you get scored the easiest story, find the mid-size one and run the same procedure. you’ll get the higher scoring, like 3. Then take a hardest story and get a third scoring, 5 points.

Eventually, you’ll get a baseline of small (1pt), medium (3pts), and large (5pts) size stories for the project. And once you’ve got that it is simple to sort all the remaining stories into one of these groups.

Agile Story Points Fibonacci Sequence

You might notice that there is a gap between the points. This is because when agile team size stories and points they leverage a Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc. This approach to story sizing in agile pursues several goals:

  • Helps us avoid false precision.
  • Reminds us that small differences are never as important as we think they might be, so the team won’t give a bigger point just because the task is different.
  • It highlights relativity in sizing between different user stories.
  • It pushes the team to better weight the efforts because there are no intermediate points between 34 and 55. Thus the team should choose one or another and stick to it.

The biggest advantage of using Fibonacci sequence is that it keeps us focused on the relativity of size. The relative size is more important than individual size.

How to Get Better Estimation of Story Points with Planning Poker


You can make such relative estimation alone, but it gets even better if you work as a team. Planning Poker is an elegant way to size stories as a group. Here’s a short play:

  1. You read the story to the team.
  2. Development team asks clarifying questions.
  3. The team makes first guess. Like bets.
  4. Team members star to argue and provide the reasoning behind their bets.
  5. During this discussion, everyone learns something new and discover an optimal way.
  6. After few more betting rounds, the equilibrium will be found and you can move on to the next user story.

This is a better way to assign points to the user stories. It gets developer the inner notion about the project and provides the client with the direct feedback. The true agile way of estimating story points is when it’s done by executor only. No one except the developers should estimate story points.

How to Convert Points to Time

Once your team has more user stories compared, estimated, and actually delivered you’ll get what’s called Velocity.

The velocity will allow you to convert point into actual time and provide yours with much better relative accuracy. That is exactly the point of velocity: to describe how much work the team can do per unit of actual time.

This is done by simply comparing the time spent to complete tasks with different story points assigned. Hopefully, companies like our own already have charts and time measurements for different tasks. Once the equation is solved, both parts client and the team should commit to this ratio and try to stick to it during the development process.

Agile software development is a group of software development methodologies based on iterative development, where requirements and solutions are progressing through a working diligently self-organizing teams. This method helps teams with the uncertainty of constructing software. It uses step-by-step, iterative work sequences that are known as sprints. According to the scrum guides, the team themself decides how long will last one sprint for 1 or 2 weeks.
The product backlog is the list of all the work that needs to get done. It includes user stories, bugs, technical tasks, and knowledge acquisition. The backlog is periodically refined by the product owner and scrum team to ensure 2–3 sprints worth of work. A reliable backlog should be quite detailed such that any member of the scrum team can work on the user stories independently.
Actual velocity involves dividing the total number of story points completed by the number of sprints. For example, if the development team has completed a total of 50 points over two sprints, the team's actual velocity would be 25 points per sprint.

Bottom Line

Within Agile the team must plan their work, so they can develop with quality and predictability. Story points are the preferred units for the calculated effort required for agile teams. This practice helps teams get good enough information while avoiding false precision.

If you need a quick turnaround and want to get value in first place, the Agile way of development will fit your project. Just get prepared to commit to the Planning Poker stage and provide clear User Stories to us.

Want to go with Agile development?

Tony Tony Sol is the business development manager of GBKSOFT, overseeing the production of all writings for both internal blog and external platforms. He is technical-driven person always looking for new benefits of merging business and software.

Leave a comment

Leave a Reply

Related services


All articles Business Company News Marketing Tips StartUp App Ideas Tech UI and Design

People are talking about

You've got
a project in mind

What's next?

Send us a message with a brief description of your project.
Our expert team will review it and get back to you within one business day with free consultation and next steps.


Nothing can be better than getting a review from our happy clients
who recommend us and trust us their business.

More good work from team GBKSOFT. All well executed. The support within GBKSOFT is excellent. Communication is good too, spoken English as well as written. Support
GBKSOFT’s performance has been very strong. We've referred them twice, which says all anyone needs to know about them. A referral is the ultimate signal we can give that these guys are great. Strong
My Project with GBKSOFT gave me the ability to develop my software while keeping a busy schedule. Ana, who was my project manager, was very professional and was always understanding of my vision and what I wanted. I would recommend GBKSOFT again to any other company or person who has a vision for their web application. Thank you GBKSOFT! Recommend
They proved to be very good and they’re very reliable as well. They are quite conscientious. They will go the extra yard to make sure we're happy. Reliable
I’ve been using GBK Soft for the past 3 years and they have been great. Communication is unparalleled to other app development companies. I’ve continued to return to them to improve my iOS app countless times and I will continue to do so in the future. I highly recommend this company! Improve
I think they do great work. I haven’t yet given them something that they were unable to do. Great
They write clean code, adhere to deadlines, and communicate extremely well. I strongly recommend anyone from the GBKSOFT agency and hope to work with them again myself. Clean Code
Gireesh, USA
One word...EXCELLENT.
Very well thought out and articulate communication. Clear milestones, deadlines and fast work.Patience. Infinite patience. No shortcuts. Even if the client is being careless (me). The best part...always solving problems with great original ideas, especially with this strange project where we are making up new words every day!
GBKSOFT did a good job to manage the project. They put in a good effort to communicate with us and make it easier for us to communicate with developers. Good Job