What is Agile estimation in project management

Agile Project Management is a way to manage software development projects iteratively and incrementally, usually supported by a cross-functional team.

Agile keeps your projects more flexible, and supports frequent delivery of product iterations (like feature launches and software updates). Using Agile Project Management, you evaluate product requirements, execution steps, progress, and outcomes continuously, so your team can respond to changes quickly.

But “Agile” doesn’t mean random or disorganized. This approach to project management follows a framework, with detailed project planning and estimation for each “sprint” before execution. Of course, as with any type of project management, stakeholders will still want to know when your work will be finished, so they can plan marketing campaigns and other promotional efforts.

Agile estimation empowers teams to plan and manage the effort to deliver a new feature or product. Without an accurate estimate, it’s impossible for anyone to know if your team is on schedule, or if the proposed schedule is even realistic.

Every team struggles with estimation at some point. The Agile Manifesto doesn’t give much instruction on the subject.

Before Mike Cohn introduced Planning Poker in 2005, estimates of the effort and time required to complete a task or project could wind up way off the mark.

Ultimately, you’re guessing, but there are shots in the dark and there are educated guesses. We’ll focus on four methods for estimating the amount of work involved in a particular task or story:

Planning Poker
Asynchronous
Relative Estimation
Bucket Sizing

You’ll learn what each method is, why (and why not) to use each one and, most importantly, how to estimate using each approach.

We’ll start with Planning Poker.

What is Planning Poker?

Planning Poker

Planning Poker (also referred to as “Agile Poker”) is an estimation technique used by Agile teams to estimate the amount of effort required to complete a project.

Planning Poker is a gamified approach to estimating story point values. The moderator will take a story or task from the backlog, discuss the details, and then each team member will share his or her estimate.

Some tasks or stories prove easier to estimate than others. Team members sometimes reach consensus easily; other times, they will need to debate for a while before reaching agreement.

Teams can play Planning Poker both in-person and virtually, in a synchronous or asynchronous way. You can sit around a table with decks of Planning Poker cards, or you can use an app, like Appfire's Agile Poker for Jira or Planning Poker.

Story points for Planning Poker

Most Agile teams use story points to rate the amount of effort required to complete a given task (or “story”). They express their rating using a Fibonacci-like number format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

The significant leaps from one number to the next make it less likely that team members will contribute several slightly different estimates for the same task or story.

Why use this method

Planning Poker works especially well for experienced Agile teams. Team members already understand how to use story points, so you’re not trying to teach them the game and the story points concept at the same time.

One advantage of Planning Poker is that every team member gives their own estimates, which encourages group discussion and collaboration. No one can monopolize the conversation because the process ensures that even more introverted team members feel empowered to speak up.

Ultimately, having the opportunity to voice concerns and ask questions during the process helps all team members feel more committed to the project plan, once created.

Planning Poker also goes pretty fast!

Why skip this method

Although Planning Poker can make estimation fun and collaborative, the game itself isn’t entirely intuitive. Newer team members can take a lot of time just learning to play, never mind coming up with accurate estimates.

Planning Poker also isn’t completely relative. In Planning Poker, items are estimated one by one, and each of them should be compared to a baseline.

But session participants often try to figure out how many times bigger the given item is than the baseline. Here is where the estimation process can get derailed.

We end up with estimations in fixed time intervals when the real idea of relative estimation is to compare items against each other.

Is this method for you?

Planning Poker works well for teams with more story points experience. Atlassian published a helpful primer on Planning Poker if you’d like more background on the method.

But if you're ready to dive in, read on!

How to use Planning Poker for Agile estimation

Step 1: Give each person an identical deck of Planning Poker cards

Give each team member a deck of Planning Poker cards.

Don’t go from 1 to 100: instead, use cards with face values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. You want big leaps so you can easily distinguish between simple tasks and more challenging projects. These values represent ideal days, story points, or whatever units your team usually uses for estimates.

Step 2: Read the story out loud

Have the product owner, product manager, or customer read the Agile user story to the team members.

Step 3: Discuss the story (skills and number of team members needed, etc.)

Answer any questions team members have, clarify any confusing points, and talk about what skills are required to complete the project. Figure out how many people might need to work on the story. Make sure everyone’s clear on the task, so they can estimate more accurately.

Step 4: Each person selects a card from the deck and shares their estimate

When you’ve covered everyone’s questions, each team member selects a card to represent his or her estimate of how long the story will take to complete. Don’t show anyone yet! Wait until everyone’s picked a card.

Once everyone’s ready, the team members all show their cards at once. If everyone chose the same number, that’s your estimate. If not, those whose estimates were much higher or much lower than average should explain their reasoning.

Step 5: Reach consensus on the estimate

Time for round two! Everyone chooses again, and this time when they throw their cards down, you’ll typically see all the same numbers. If not, you might need to continue the conversation.

Let’s try it out! We’ll use “Interactive Mode” in Agile Poker to show you how it’s done, but you could also use Planning Poker for Jira.

You can even use Planning Poker for Jira for distributed teams

A product owner, ScrumMaster or Agile coach just logs into the tool and preloads a set of items to be estimated. Then they share a private URL with team members who log in and join a conference call or Skype session. Agile estimation and planning then proceeds just like it would in person (except for the donuts in the conference room).

What is Asynchronous Estimation?

Asynchronous Estimation

Asynchronous Estimation is another approach used to estimate the amount of effort required to complete a project. This method is similar to Planning Poker in that each team member shares their estimate.

The difference is that the team doesn’t share estimates in person or in real time: team members participate virtually on their own schedule. It is frequently used by teams working remotely, especially ones who have members living in different time zones.

Text intro: Planning Poker works great for teams working together on-site or online in the same time zone. But many teams now work remotely, with members spread out across many time zones. For these teams, an asynchronous approach to estimation works best.

Asynchronous estimation is inspired by Wideband Delphi, a consensus based approach to estimation.

Why use this method

Asynchronous estimation ensures that all team members (wherever located) have the opportunity to voice their concerns, and all estimates receive equal consideration. Team members estimate on their own, at their own pace.

Some teams use a hybrid approach, using Asynchronous to get familiar with the stories, cast their initial estimates, and address concerns through comments.

Then they meet in real-time to play Planning Poker.

Why skip this method

Asynchronous (or Async) lacks some of the benefits of Planning Poker, like the opportunity for real-time collaboration and conversation.

One potential drawback to Asynchronous is that if you need to add a new task or break a story into two, the moderator will need to create a whole new session. In synchronous Planning Poker, the leader can add the task then and there, and the team will estimate it right away.

Is this method for you?

Asynchronous estimation works well for distributed teams that have members in different time zones.

If you're ready to try it, read on!

How to use Asynchronous Agile estimation

Step 1: Select the stories to be estimated

Post the stories to be estimated. Be sure to include all relevant details, and try to anticipate questions (like skills required, number of team members needed, how you’ll handle any roadblocks or bottlenecks, etc.).

Step 2: Team members post estimates and comments backing up their vote for selected stories

Each team member submits an estimate privately to the person organizing the session.

Step 3: Once everyone's participated, the session moderator reviews and saves votes

The person in charge of completing the work (usually the product owner or product manager) submits estimates based on each team member’s personal scores and comments.

Step 4: Take stories without consensus into a new round of asynchronous estimation or schedule an interactive Planning Poker session

Give team members an opportunity to explain their estimates if they were much higher or lower than average. They can also answer questions posted by other team members. You might choose to schedule a real-time, interactive Planning Poker session if you need more discussion.

Some teams prefer to discuss estimates and reach consensus during an interactive Planning Poker session, scheduled once everyone’s initial estimates are in.

Step 5: Post estimates again and reach consensus

The person in leading the charge submits final estimates based on each team member’s second-round scores and comments.

Here’s how you do it! We’ll use Agile Poker for Jira to show you:

What is Relative Estimation?

Relative estimation

Relative Estimation is a way to estimate the effort required to complete a project by comparing each task to another one. (You should already know how much effort the reference task will take based on past experience.)

Using Relative Estimation, you choose one task to serve as a point of reference. Then estimate every other story as taking less effort or more effort than that one.

This approach is based on a widely known method of estimating known as the “Magic Estimation Game,” also known as ‘silent grouping’ or ‘affinity estimating.’ (It’s known as “Relative Mode” in our Agile Poker for Jira app.)

In this exercise, your team focuses on estimating product backlog using story points in a limited amount of time. Instead of estimating tasks or stories individually, you compare or group tasks of similar difficulty or effort.

Why use this method

One criticism of Planning Poker is that it’s not relative, so estimates for individual tasks or stories might not make sense when you look at the project as a whole.

Relative Estimation, by definition, involves estimating effort in relation to other tasks.

Relative Estimation is also visual and interactive, which can make this solution easier for remote or distributed teams. Participants can see the tasks or issues to estimate relative to one another. At a glance, they can compare items or issues by placing them in the appropriate columns.

Relative Estimation is easier to set up, moderate, and manage. In minutes, a Product Manager, Product Owner, Scrum Master, or Project Manager can set up an estimation “board” using a tool that supports Relative Mode. You can be done estimating in a fraction of the time it would take to explain Planning Poker to a team that’s never used it.

And along those lines, Relative Estimation works great for teams that have a low to moderate experience using Story Points for estimation. Team members don’t need to come up with estimation values: just compare one issue to another. Simple!

Relative Estimation generally produces accurate results in less time. A session facilitator can easily move tasks or issues into a column for estimation, get estimates from the team, then move onto the next task—all in one view!

Why skip this method

If you’re trying to get the estimation process done faster, Relative Estimation won’t necessarily get you there. You’ll spend less time on logistics and set-up (explaining the game), but you’ll still need to discuss and deliberate if people can’t agree. If you’re familiar with Planning Poker and that process usually moves quickly for you, switching might not be worthwhile.

Is this method for you?

Relative Estimation works well for less and more experienced teams alike, provides a visual representation during the process, and enhances interaction. If you’re sick of awkward silences stretching out your meeting or Zoom call, give this visual method a try!

If you're ready to try Relative Estimation, read on!

How to use Relative Estimation

Step 1: Select the stories to be estimated

As with any estimation method, you’ll need to select the stories to be estimated.

Step 2: Agree on a reference story card (usually the smallest one) to compare with the rest as you go

Choose one story card to serve as a reference—the one you’ll use as a guide to sort the rest. This will usually be the smallest story.

Step 3: Estimate each story relative to the reference (more or less effort / time / complexity to complete than the reference), and to other cards you place on the board in the course of the estimation session

For each story card or task, team members estimate whether it will take more time and resources or less as compared to the reference story and other items already placed on the board.

Place it in the appropriate size category.

This process tends to go quickly, as the human brain is hardwired to compare one thing to another.

Step 4: Estimate the time / effort / complexity to complete all stories in each size category

Add up the estimates for all stories in each category, then sum the totals to get an estimate for your entire project or backlog.

Here’s how you can do it using ‘Relative Mode’ in Agile Poker for Jira:

What is Bucket Sizing?

Bucket Sizing

Bucket Sizing is an estimation technique where your team sorts issues into predefined columns based on their estimation values.

It’s a little like using Relative Estimation, but more focused because your estimation values (your “buckets”) are already set. Team members just drop each issue into the right size “bucket.”

Why use this method

Bucket Sizing can move faster than Planning Poker because there aren’t as many rules to explain. Sorting is easy, after all! And you still get accurate and reliable results.

Estimating tasks with Bucket Sizing can be a lot of fun because of the many ways to illustrate size (like using coffee cups, pictures of small and large dogs, etc.).

Why skip this method

If you have less experienced team members who might benefit from a discussion of how other members choose where to place each task, Planning Poker or Relative Estimation might be a better option.

Is this method for you?

Give Bucket Sizing a try if you have a big team or a lot of items to estimate. This approach also works well if you work with teams to estimate effort or collaborate with stakeholders to estimate value.

If you're ready to try Bucket Sizing for Agile estimation, let’s go! We’ll use Bucket Sizing mode in Agile Poker for Jira.

How to use Bucket Sizing

Step 1: Select the stories to be estimated

Step 2: Discuss the story (skills and number of team members needed, etc.)

Step 3: Set up several "buckets" of different sizes (small, medium, and large)

Some teams take a “sizing” approach, using t-shirts or dogs to illustrate the different sizes. You could use anything. Different size coffee cups, nesting dolls, books...anything easy to visualize! Buckets are simple, because you’ll be filling each “bucket” with story cards / tasks. Arrange your buckets from smallest to biggest.

Step 4: Team members choose a bucket for each item from the project or backlog

Team members take turns, each placing an item into what they think is the appropriate bucket. The next team member places the next item from the stack of cards into the bucket with the relevant estimate.

Instead of placing a new card, a team member can choose to move a card placed by another team member into a different bucket if they estimate that item differently.

This step continues until all items from the stack are assigned an estimate. No one’s talking about the tasks at this point: they’re just moving cards when it’s their turn.

The product owner / product manager / session moderator keeps track of any items that are moved several times so the team can discuss them during the final step.

Step 5: Review, discuss, and reach consensus

Team members now discuss any items that bounced around from bucket to bucket. Once everyone’s had the opportunity to explain their reasoning, the group reaches consensus.

Here’s how you do it. We’ll do it using Agile Poker for Jira, but you could do it analog using sticky notes and a wall or whiteboard (or actual buckets, if that sounds like more fun)!

Download all cheat sheets

The ultimate guide to Agile estimation, from planning poker to bucket sizing

Subscribe for updates