Story Point Estimation – How to Use Agile Story Points

This article includes excerpts from our eBook. For the full guide to building a collaborative software team, pick up your free copy!

Software project estimates are, essentially, the art of guessing.

In agile development, the bigger a project is, the less accurate an estimate will be. The further away the delivery of that project is, the less accurate its estimate will be.

Accurate or not, people will still want to know when a particular feature will be shipped.

At the beginning of a project, estimates are bad guesses at best. In contrast to waterfall development, most agile teams now add detail about tasks as they discover more about the tasks and the project. You won’t know much at the beginning of a project – and that’s okay.

One person might say estimates have no place in software development, while others will agree that using estimates is what defines agility with respect to development.

Despite estimates not being a one-size-fits-all approach, we wanted to add some clarity to the discussion and share how bringing estimates into sprint planning can help bring open up greater communication across software teams.

Let’s jump straight to it!

What is story point estimation?

People aren’t very good at guessing how big something is in absolute terms, like hours or days. But we’re surprisingly decent when it comes to sizing something up in relation to another thing.

For example, if you give a person two piles of beans, they probably won’t be able to tell you how many beans are in each pile. However, they should be able to say one pile is about twice the size of the other pile.

That’s the basis of Agile story points.

Story points involve relative estimation. They’re unitless scales of measurement which are sized in relation to other tasks. Unlike hours, which are based on consistent values, story points are based on arbitrary measurements. Their only purpose is to compare a task in relation to the sizes of your other tasks and see how much effort is needed to complete it.

Agile projects prefer a point-based system because you don’t need to stress about how your “actuals” compare with your “estimates”. Relative estimates remind us that they’re not meant to be used as a deadline.

Agile story point estimation vs. time estimation

Agile development deals mainly with two types of estimates: Agile story points and time.

In contrast with story points, time estimates are useful only when you have enough information – which is to say that you should use them when your development team has gathered some detail and done some discovery work.

Time estimates refer to the actual productivity of real living people. What takes Sarah three hours could take Sam two days. That’s why nobody but the people coding should be estimating time. If you’re adding time estimates, consider the issue’s scope fixed.

When should you estimate?

There’s no perfect answer to this, but here’s what we recommend.

Before anything is ever estimated, GitHub issues should be broken into more granular chunks as some discovery work has been done. Probably, that means they’re in the product backlog (the backlog pipeline without a Milestone.)

Adding agile story point estimates at this stage will inform the next step: deciding which Issues to add to a Milestone. Issues that have a Milestone and an estimate will appear in your reports, like Velocity Charts and Burndown Charts. As a result, you’ll be able to see how your projected team velocity compares with reality.

Some people use time estimates; others use story points. After trying a couple of methods, here’s what we’ve landed on:

First, we don’t spend time estimating tasks until we’ve done some discovery work. To keep overhead as low as possible, issues that are in our Icebox never get estimated.

At this point, our issues have been broken down into consecutively smaller chunks as we learn more about them. This probably means they’re sitting in our product backlog (the backlog pipeline with no Milestone attached.) By adding estimates at this stage, we’ll easily be able to construct our sprint backlog (that is, which issues to add to our next GitHub Milestone.)

Issues that are estimated and turned into Milestones automatically appear in our Burndown charts. When an issue is closed, a new data point will appear on the chart. As a result, we can see how our projected speed of work compares with our reality.

Why bother estimating development tasks?

Estimating a task is helpful when putting together your sprint backlog. Given a set amount of time – say, two weeks – and a set budget, how can you tell which GitHub issues to tackle if not for estimates?

When paired with historical data in the form of burndown or velocity charts, your team can see how fast you’re actually going, which is an invaluable planning tool.

Other benefits of sizing include:

• Getting an overview of the project’s scope
• Fixing past assumptions through accurate estimates
• Using the feedback of different members to conclude how long tasks [currently still in the product backlog] should take
• Giving your team a better understanding of the complexity of the project’s requirements
• Allowing product owners to track the ROI of each action item

There’s a big difference between plotting a satellite’s course to Jupiter’s orbit and estimating a timeline for software development tasks.

The former requires dozens of people with MENSA-level IQ scores and billions of dollars in funding; the latter requires something more akin to a homemade compass and a gas station map.

You just need to have a general idea of where you’re going and the route you’re going to take to get there.

How should you estimate?

There are many ways to go about estimating software. Whether you use triangulation, planning poker, or some other estimation method, you should always remember to prioritize two things:

• Your Team: Never estimate alone. Harness the wisdom of your team. Your estimates will be better, and your team will like you more!
• Speed: Remember not to get caught up in the tiny details, because you’re still only guessing.

Software estimation techniques to consider

There are a few main ways you can tackle the challenge of estimation:

Planning poker

Everyone on the team gets a set of cards with point estimates. When an issue is read, each engineer holds up an estimate card they feel is appropriate.

The benefit of this method is a discussion, not compromise: if Sarah and Tim hold up one and seven respectively, don’t give the task an estimate of four. Talking about why your estimates are so different can reveal miscommunications about the scope, which is helpful.

T-shirt sizes

T-shirt sizing is an agile estimation technique that is an easy way for teams to associate values with Issues without having to over-analyze them.

Using T-shirt sizes (XS, S, M, L, XL) guarantees you won’t over-analyze things, and they’re yet another reminder that your estimates can’t be equated to measures of time. Have your team come up with a range of story points that equal an XS, S, L, and so on. If something is an XL, consider breaking it down into several smaller tasks.

Once the range of points is set, T-shirt sizing is the quickest way to decide how difficult Issues are and which ones can be prioritized into an upcoming sprint.

Triangulation

Triangulation is just a fancy word for “matching like with like”.

Take your issues and choose one that’s a definite one. Take another that’s an estimate of ten. And another that’s somewhere near the middle. Now you have a basis on which to estimate the rest of your issues comparatively.

Match the rest of your tasks relative to these baseline estimates: Is this issue bigger or smaller than my “one”? Keep going until all your issues are estimated relatively.

How to estimate story points in ZenHub

To get started with estimation in ZenHub, head to any Issue. Once in an Issue, on the sidebar will be a section for setting an Estimate.

By default, ZenHub comes with default story point values that follow the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, and our own twist on the sequence to symbolize the largest story point value of 40.

The Fibonacci sequence is a popular Scrum method to follow when estimating work to be done as the agile story point values get significantly larger numbers. Going from quite small values to significantly large numbers reflects the uncertainty of estimating larger items.

A high estimate usually means that the work being estimated is not well defined. This uncertainty can create misunderstanding. Work that gets assigned a high story point value should be broken down in detail or transformed into multiple, smaller pieces of work.

Once you have an estimated value in mind for an Issue, simply click on an estimated value from the Estimate dropdown.

Changing estimates and story point values

Need to customize the story point options in the Estimates dropdown? To delete an existing story point option from the list of options hover over the story point. Clicking the trash can that appears on the right of the story point will remove it from the list.

Deleting the story point will permanently remove the estimate across all Issues where it has been assigned. Be sure to talk with your team before permanently deleting a story point option.

To add a new story point option simply type the value you would like to add as an estimate. This will prompt you to create a new value.

Sort issues on the board by estimate

Once you have estimated Issues, you can sort each pipeline on the ZenHub Kanban Board by story points. Click on the Sort pipeline option and select Estimate to get a complete picture of the estimates of most Issues in the workflow.

Estimate issues in bulk

Whether you are starting your Sprint or doing some cleanup on the Board, you can leverage the **multi-select action bar** to assign estimates to a grouping of Issues.

Software estimates have long been considered a challenge – but with a little practice, some experimentation, and some historical data, your team will be rewarded with more predictability and greater confidence in your development process. Are estimates worth doing? We’d guess so.

For teams getting started with story point estimating we’ve created a helpful guide on how to estimate in agile project management. If you have any questions, you can reach out to our Customer Success team who are happy to walk you through how to start using estimates.