How to Estimate with Story Points in Agile

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 in Agile 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.

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 in agile are a complex unit that includes three elements: risk, complexity and repetition.

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:

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.

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.

Step 3 — 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 in Agile 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.