Agile Development 101 – Story Points Estimation Guide

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

You 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. This 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.

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

.

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.

FAQ

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.