Agile Team Guide To Estimations

Agile
The Agile team’s

comprehensive guide
to acing estimations
5 methods to help you eliminate backlog headaches
and get your Agile estimations right.
From Appfire
Supporting Agile product development from
ideation & planning through to delivery
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
What is Agile estimation in project management? . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What is Planning Poker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Story points for Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Benefits of using story points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Why use this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Why skip this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
How to use Planning Poker for Agile estimation . . . . . . . . . . . . . . . . . . . . . . . . . 10
You can even use Planning Poker for Jira for distributed teams . . . . . . . . . . . . . . 11
What is Asynchronous estimation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Why use this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Is this method for you? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
How to use Asynchronous Agile estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
“Hybrid” Poker: The next generation poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Benefits of Hybrid Poker for Planning Poker users . . . . . . . . . . . . . . . . . . . . . . . 15
Benefits of Hybrid Poker for Async session users . . . . . . . . . . . . . . . . . . . . . . . . 16
Hybrid Poker in Agile Poker for Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What is Relative estimation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

How to use Relative Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
The Agile team’s comprehensive guide to acing estimations 2

What is Bucket Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
How to use Bucket Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Planning Poker: The gold standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

What is Priority Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Prioritizing with Priority Planning Poker in the Agile Poker app . . . . . . . . . . . . . . 26
How can Agile Poker for Jira help you with backlog estimation? . . . . . . . . . . 29
How do I make estimation work better? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Agile estimation is a team effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Download all cheat sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appfire Apps that help with estimations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Introduction
Introduction
Estimating the amount of effort projects require can be tricky. We get it.
But with Agile project management, you have some options that make
estimation easier.
In this guide, we’ll discuss how to manage estimation in an Agile

environment, and we’ll explain some of the most popular methods for
estimating with Agile teams. You’ll also find some helpful cheat sheets and
links to our favorite estimation apps.

What is Agile estimation in project management?
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. And 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.
Even using a tried and true Agile estimation method, you’re still guessing. But there are shots in the dark
and there are educated guesses. We’ll focus on five methods for estimating the amount of work involved
in a particular task or story:
• Planning Poker
• Asynchronous
• Hybrid Poker
• 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 (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 or work
involved in a particular task or story. This is often expressed in a Fibonacci-
like 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.

Things to know when using story points for estimation:

• Story points represent the relative measurement of effort to deliver the story: the amount of
work to do, the complexity, and any risk associated with this story.
• Story points do not measure the time spent on a story.
• Estimating in story points is typically faster than estimating time.
• Specific days, dates, or hours don’t account for your team’s day-to-day tasks or activities that
are unrelated to the project you’re estimating. This includes answering emails, meetings, or
other task management activities throughout the day.
• Because estimations are relative, they should involve comparing stories based on what’s
known about the story you’re estimating. You’ll also want to consider team members’ past
experiences with similar tasks.
• Encourage discussion to make sure all team members are on the same page about the
scope of work. (NOTE: The relative weight should be similar for every member at the same
seniority level — juniors, mid, or seniors.)
• Once the team’s agreed on each story’s required effort, it’s easier to assign story points to
development teams without debate or surprises.
Benefits of using story points

tory points are faster, better, and cheaper than hours, and the highest
S
performing teams completely abandon any hourly estimation as they
view it as waste that just slows them down.”
Sutherland, J. (2013). Story Points: Why are they better than hours?
Let’s review the benefits of using story points.
Estimating in story points is fast. Teams who estimate in days tend to take
the discussion a few levels deep. If you estimate in days, fear of commitment
makes people hesitant to reach consensus.

As Jeff Sutherland observed, one CMMI level 5 company determined that

story point estimation cuts estimation time by 80%, freeing teams up for
more productive project activities.
It’s relative. Mike Cohn best described it in Agile Estimating and Planning:
ecause the estimate for each feature is made relative to the estimates
B
for other features, it does not matter if our estimates are correct, a little
incorrect, or a lot incorrect. What matters is that they are consistent.
And indeed, ‘there is credible evidence that humans are good in relative
estimation compared to absolute.’”
Cohn, M. (2005). Agile Estimating and Planning. (1st ed.) Prentice Hall.
STORY POINTS REMAIN THE SAME FOR EVERYONE.

It doesn’t matter if a senior or junior developer will deliver the story. What
matters is that the story is X times bigger than the reference one.
Estimating in story points allays team members’ fear of commitment. When

estimating using hours, you make a precise time commitment. Estimating
in story points prevents giving an exact time commitment. Nobody knows
precisely how many hours you are appointing to a specific Item.
ELIMINATES THE NEED FOR FREQUENT RE-ESTIMATION.

When planning with story points and velocity, we essentially take those points
as size-based estimates. We don’t expect the size of the story to tell us the
time needed to complete it. If estimates are in days, the team finds itself in the
position of needing to frequently re-estimate future stories based on current
knowledge.
When teams talk about “days of work,” it implies a level of specificity that
isn’t real. We avoid this problem when using story points. The fact that a
team learned to work twice as fast gets reflected in their velocity. As long as
the story sizes are consistent (read the previous points) between stories, no
re-estimation is necessary for planning to occur.
STORY POINTS ENCOURAGE CROSS-FUNCTIONAL COLLABORATION.

Mike Cohn explains this very well in his book Agile Estimation and Planning.
Agile teams include people from different disciplines like programmers,
analysts, testers, designers, or product owners. Agile projects benefit when

each team member thinks about a built feature first and then their role as
a specialist contributor. As a result, estimating in story points helps teams
learn to work cross-functionally.
Because a story point is a single number, all team members need to

consider the big picture when estimating — to think of the item as a
complete feature. They need to shed any departmental mindset about how
much time a programmer or tester or UI person would take and any effort to
add that to their estimate.
At the end of the day, scores are made up. They’re just numbers.
It’s the conversation and collaboration that happens during the estimation
session that brings value and helps team members gain a common
understanding of stories.
The team behavior takes precedence over individual preferences as

conversations result in team building, with team members constructively
criticizing one another, and engaging in healthy debate.
Now, back to Planning Poker.
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 actual purpose
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 like to use “Interactive Mode” in Agile Poker, but you
could also use Planning Poker for Jira.)
Download Cheat Sheet
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?
What is Asynchronous
estimation?
Asynchronous (or Async) Poker was introduced in Agile Poker for Jira and
quickly became popular due to a lack of alternatives for teams distributed in
different timezones or even spread across various office locations.
Instead of finding a timeslot that suits all the participants (that might be
challenging to achieve), players were able to provide estimates at their own
pace in a given timeframe, providing detailed comments explaining each
personal estimate.
Usually, the person responsible for planning submits final estimates based
on personal scores and comments from the team.
Asynchronous estimation is inspired by Wideband Delphi, a consensus-

based approach to estimation.
Learn more about Asynchronous Poker.
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.

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.

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 session organizer.
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 leading the charge submits final estimates based on each team
member’s second-round scores and comments.
Here’s how you do it!
Rules of Agile estimation meetings:

• Scrum Master is a facilitator of this meeting and should not be
taking part in the discussion, but he or she needs to follow the
discussion and be able to keep it on the rails;
• Product Owner prepares and explains Backlog Items for the

estimation;
• Only the development team members can estimate and discuss

Backlog Item efforts;
• The Product Owner prioritizes the Product Backlog based on

business value, and priorities are aligned with business needs;
• The estimation method is chosen by the team upfront and known

by all team members;
• The estimation session should ideally be separated from the

planning session;
• The Sprint Backlog Estimation session should be timeboxed, ex.,

2 hours per 2-week plan (modify it with the same relation if your
typical Sprints are different).
Need a little extra help? Here’s a simple checklist for effective

estimations that will support Scrum Masters and Product Owners who
estimate together with the development teams.

“Hybrid” Poker: The next generation of poker
“Hybrid” Poker: The next

generation of poker
Now, let’s look at a concept that some Agile Poker users call the next step
in Planning Poker evolution — the hybrid of Asynchronous and classic
interactive Planning Poker.
Let’s call it Hybrid Poker for convenience.
Hybrid Poker is a combination of Asynchronous and Planning Poker. It’s very

popular among Agile Poker users, who previously used either Interactive or
Async estimation sessions for their backlog estimation.
In three simple steps, the process of estimation in this hybrid mode looks
like this:
1. One of the team members creates an estimation session several days

before the refinement or planning, specifying the session scope and
sending invites to the team informing the team members about the
scope and a deadline when they should submit their personal estimates.
2. Team members estimate at their own pace at any time before a specific
due date, additionally leaving comments explaining personal estimates
or pointing out missing details. There is no additional discussion taking
place at this point.
3. When the final estimation session starts, the team gets together and can
discuss user stories’ results if the consensus was not reached with the
ability to reset estimates and carry out the voting interactively.
Benefits of Hybrid Poker for Planning Poker users

Let’s imagine members of a team that used to do Planning Poker. They come
to the final estimation or refinement session with all personal estimates
provided and a complete understanding of issues details easily. That team
also has a moderator who has read through all the comments and was able
to adjust some user stories, break down the others and provide the missing
information. In this case, the session is swift, and here is why.

• While doing personal estimates, team members can quickly go

through the user stories since they are already familiar with them (in
the classic Planning Poker, they would have to wait for others who
need more time to cast their estimate)
• Participants of different seniority can spend proper time to

understand each issue, not holding on or waiting for others,less
experienced teammates
• The moderator provides extra information missing from tickets
• The moderator can address participants’ comments with some

additional actions, like breaking stories in two, adding missing
acceptance criteria, providing extra feedback from business people
prior to the final estimation session; all the missing activities with the
backlog like breaking down user stories or creating new ones based
on the comments are done
• The team already provided personal estimates, so only re-estimation

to reach a consensus will take extra time
Benefits of Hybrid Poker for Async session users

Imagine a team that used to do Async Poker and can get together — maybe
partially — for a short estimation session because the final estimation will be
very quick now. Here’s what this means.
• All the Planning Poker benefits mentioned above stay because the
final estimation session takes place
• Personal estimates are faster because there’s no need to be highly

detailed with estimation comments
• The team can re-vote and reach consensus
• The team can estimate new stories or tasks right away
Even better, the Hybrid session is flexible, so you can adjust the process to
suit your team’s needs.

Hybrid Poker in Agile Poker for Jira

Follow these simple steps below to run Planning Poker in Asynchronous
mode in Agile Poker:
• Make sure you install Agile Poker for Jira first.
• Navigate to a Jira project and select your board.
• Click on Agile Poker from the board menu and create an

Asynchronous session.

• Specify participants, settings, and scope of the session. Optionally,

send session invitation emails, don’t forget to mention a due date.
• Wait for the teammates to provide personal estimates.
• When the due date rolls around, enter the session and click on Review
personal estimates.
• Address questions, concerns, and suggestions raised in the

comments.
• Invite the team for a short Final estimation session by sharing the
session link with them.
• Submit final estimates for the session scope. Don’t forget to reach
consensus by re-estimating issues during an interactive Poker game.
Agile Poker for Jira helps you optimize work and save hundreds of precious
working hours. If you’re ready to put it into practice, try Agile Poker for Jira.

What is 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!

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.

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

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.
You can do this using Relative Mode in Agile Poker for Jira, or you can do it
using a physical whiteboard or sticky notes.

What is 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.).

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.

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! Here’s how
you do it. We use Bucket Sizing in 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)!

How to use Bucket Sizing
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.

Planning Poker: The gold standard
Planning Poker:
The gold standard
Still unsure which estimation method is the best for you? Almost 20 years
after its introduction, Planning Poker is still the gold standard for estimation
in most Agile teams, and it’s not hard to see why. Planning Poker:
• encourages group discussion and collaboration
• leaves team members with a shared understanding of every story
• has an engaging game flow
• results in unbiased estimation because you get everyone’s point of view
• allows team members to feel more committed to the project plan
• is relatively fast
Although Planning Poker might seem like a fun way to estimate effort and
work as a group, the process of the “game” or technique itself isn’t entirely
intuitive. It can take a significant amount of time to figure out how to play the
game in the first place and then come up with accurate estimates.
Planning Poker offers additional techniques like (Priority Planning Poker)

that could work better for your team, depending on your needs.

What is Priority Planning Poker

Priority Planning Poker is a technique that product development teams can
use to ensure that everyone contributes to the prioritization of work items.
It also gives every team member a way to easily decide how they can best
contribute to the work.
This method allows people to participate in a democratic, fair, and

transparent estimation session to help them make group decisions on the
coming weeks’ priorities.
The fundamentals of the Priority Planning Poker method are simple. This
method ensures the entire team makes decisions free of biases. It’s entirely
fair, so everyone feels included.
ips for running a successful Priority

T
Planning Poker session:
• Create a virtual room where you can present selected issues for
your next sprint.
• Invite your team members to the session.
• Present work items that need improvement or to be worked on.
• Allow everyone to participate in the discussion and enable them

to assign points to tasks.
• Show the results of the voting.
• Discuss when necessary, accept the vote, or ask participants to

vote again if the votes differ substantially.
• Start working on your tasks according to the priorities set

during the Priority Planning Poker session.

Prioritizing with Priority Planning Poker in the

Agile Poker app
Using the Priority Planning Poker method, you can prioritize your work items
within the Agile Poker application.
You can support this estimation process and help your team prioritize their
work with Multi-field estimation in Agile Poker for Jira. Backlog estimation
is a core aspect of successful planning for hundreds of agile teams. This
method will allow you to estimate several Jira fields at once and then
calculate the final score (or value) based on those estimates.
To start your estimation session:
1. Create an interactive or asynchronous session in the Agile Poker app.
2. From the Multi-field estimation toggle, choose between several pre-

defined templates or create a custom one where you can estimate up to
five fields. Pick one of the following templates: Ability and Impact, ICE,
RICE, WSFJ, or PERT prioritization frameworks.

3. Select appropriate Jira fields for estimation.
4. Enable the Final score toggle to calculate the outcome of the entire
session.
5. Modify the criteria if needed.
Once ready with the configuration, run the estimation process. Depending
on the type of session you choose, you can do it in real-time or let everyone
go at their own pace. The estimates are private until everyone’s ready
to assign estimates. Only then can you show the results and start the

conversation. Some votes may be very similar, and reaching consensus

within a team will be easy. Other times, you might need to re-estimate.
Estimations may differ too much because someone lacks experience, because
they’re over- or underestimating, or because they simply made a mistake.
Whatever the scenario, the team has to discuss why the results are so
different and agree upon a new estimation value for a particular work item.
After the group reaches consensus, then you can move forward to the next
issue or finish the game.
Save the final estimates in corresponding Jira fields once you and your team
are happy with the estimates. As an outcome, you’ll have a list of user stories
with a well-discussed, adequately estimated, and automatically calculated
priority score that can be used for further planning.

How can Agile Poker for Jira help you with backlog estimation?
How can Agile Poker for

Jira help you with backlog
estimation?
Most estimation methods share the same disadvantage — they’re not based
on clear data, but mainly on the team’s experience and collective thinking.
How can you make your backlog estimations more reliable in the long run?
Be consistent, use the same process and approach for your estimations,
educate your team members based on your past estimations, and build
confidence in your estimations for the future.
Agile Poker for Jira will help you keep the process, approach, and tool
elements intact. Combined with your team’s time, effort, and experience,
you’re set up for reliable backlog estimations.
Let’s dive deeper into some examples from the above checklist to see how
Agile Poker for Jira can support your estimations.

How can Agile Poker for Jira help you with backlog estimation?
ACCESS TO PRODUCT BACKLOG AND FULL SYNC WITH YOUR

ESTIMATIONS RESULTS
With Agile Poker, you have a full synchronization checkbox already
completed. You can edit, update, and insert estimation results into backlog
Items straight in Agile Poker during the estimation session, giving the
visibility of all inputs to your teammates and the whole organization.
CUSTOMIZE YOUR ESTIMATIONS TO YOUR TEAM’S NEEDS

Agile Poker gives you the flexibility to choose estimation values that fit your
team’s preferences. You can adjust and use multiple methods based on
lessons learned from previous estimations. Save and share your customized
estimations values and allow other teams to use the same approach.
ESTIMATION BASED ON THE REFERENCE ISSUES

To have reliable estimations for the backlog Items that were already
delivered, try to estimate based on how much effort something took in the
past. Reference issues could be viable primarily for teams working in big
companies or on complex projects as the knowledge flow can be limited
between teams there.
REMOTE OR DISTRIBUTED TEAMS HAVE THE SAME ACCESS TO ALL

INFORMATION FOR EACH BACKLOG ITEM
Your team has all the information needed to estimate backlog items
available in Agile Poker before and during the estimation session. This
means distributed or remote teams can estimate the same way as co-
located teams. Agile Poker is synchronized with your product backlog in Jira,
so every update is instantly visible to team members.
ESTIMATION RESULTS ARE ADDED TO THE BACKLOG ITEM AFTER

FINISHED VOTING
No more summaries, no more notes — all your estimations will be added to
your backlog Items right after your team’s done with the estimation session.

How do I make estimation work better?
How do I make estimation

work better?
At some point, every Agile team faces the need for estimation, and the vast
majority is (or will be) using story points. Here are some recommendations
from Agile Poker users as to how they address estimation challenges:
Start with Relative Estimation. As we mentioned before, story points are

often translated into time. From the very first estimation, team members will
be tempted to fall back on time instead of coming up with some other unit of
measurement to estimate effort.
Suggestion: Avoid story points completely at the beginning. Use the Relative
Estimation method of Agile Poker instead, where your team can group user
stories into columns according to their relative weight and only then assign
story points values.
This approach has worked for numerous Agile Poker users, who, after
several Relative sessions, switched to Planning Poker, Bucket Sizing, or
stayed with Relative.
Know the basics and adjust accordingly. Make sure someone on the team
knows the basics of story points estimation and can present to the rest of
the group. (Maybe that person is you!) But the important thing is that there’s

one person who can help answer questions when the team is applying new
productivity methods.
Prevent estimate inflation. In Agile Poker, we implemented two features

to help keep estimations consistent:
• Reference issues are constant stories with different story points

values used as a baseline for estimates.
• Triangulation issues constantly change and display recently finished

stories from the same project (with the same labels and components)
to give users more context of a selected story point value.
More theory on this topic might be found here.

TRY DIFFERENT ESTIMATION METHODS.

There are many different estimation methods for story points estimates,
but Planning Poker is usually the default. This might be limiting for some
teams. Many organizations use Bucket Sizing with a voting option as a faster
alternative.
If your team is remote, you may want to consider using Async Poker, which
enables estimators to go through the list of stories on their own, get into
details if they need to, and have time to explain their choice in the comment
section.
DISCUSS INCORRECTLY STORY-POINTED ISSUES IN RETROSPECTIVE.

Every now and then, the team story points an issue and it becomes clear
later that the estimate was entirely wrong. It’s important to discuss these
issues and learn from them, so future estimations are more accurate.
ADOPT.
No one knows your team better than you. If you see problems or difficulties
with story points estimation that aren’t addressed in the books and theory,
keep adjusting until you solve those problems.
Be sure that you’re estimating the right way, every time. Use this Agile
estimations checklist for Scrum teams at every standup, and stay consistent
with your processes.

Agile estimation is a team effort
Agile estimation is
a team effort
Agile estimation should involve the entire team — product owners,
developers, designers, testers, etc. It’s critical to ensure accurate estimates
as each team member has a different perspective on the product and the
work required to deliver a user story.
Team members often think estimation is just for the product or

development team because estimating only involves the development
team’s time. But that’s not the case. All the core functional areas of
designing, developing, and bringing a product to market should be involved,
and estimation should consider all these areas.
Moreover, the choice to only include the development team in estimation

exercises can lower the morale of other core functional teams who also play
a crucial role in the project. That’s why it benefits everyone to implement a
fun, interactive, and productive Agile estimation approach. For remote or
distributed teams, it’s a great way to get involved and feel valued.
Whatever your team does, estimations are part of the process. Get them
done faster (and better) with a little help from a few simple cheat sheets.

Download all cheat sheets
(AND A BONUS CHECKLIST!)
Bonus... Agile estimation checklist for Scrum teams

Appfire Apps that help
with estimations
These Appfire apps can make your estimations
faster and more accurate.
Agile Poker for Jira Planning Poker for Jira
A flexible toolkit that gives teams a choice Facilitate agile team discussion aimed at
of estimation methods for refinement and reaching accurate and consensus-based
planning estimations
Provides four collaborative estimation Estimate your product backlog during an

methods that support refinement, sprint interactive consensus-based game as part
planning, PI planning, and prioritization of the Agile framework.
based on the team’s needs, experience, or
backlog size.
Learn more and try free Learn more and try free
About Appfire:
Appfire is a global authority in the Atlassian ecosystem. Appfire’s popular solutions help teams
with Workflow Automation, Product Portfolio Management, IT Service Management, Document
Management, Business Intelligence and Reporting, Administrative Tools, Agile, Developer Tools,
and Publishing. The company has the most widely adopted portfolio of apps on the Atlassian
Marketplace, with 225,000 active installations worldwide. Learn more at www.appfire.com.
Notice of Liability
The information in this book is distributed on an “As Is” basis, without warranty. The publisher assumes no responsibility for
errors or omissions, or for damages resulting from the use of the information contained in this book. Use of the information
and instructions contained in this work is at your own risk.
© Copyright 2022 Appfire Technologies, LLC. All rights reserved.

Agile Team Guide To Estimations

Uploaded by

Copyright:

Available Formats

Agile Team Guide To Estimations

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Team Guide To Estimations

Uploaded by

Copyright:

Available Formats

Agile

The Agile team’s

What is Agile estimation in project management? . . . . . . . . . . . . . . . . . . . . . . . . . . 5

What is Planning Poker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Benefits of using story points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Why use this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Why skip this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

How to use Planning Poker for Agile estimation . . . . . . . . . . . . . . . . . . . . . . . . . 10

What is Asynchronous estimation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Why skip this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Is this method for you? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

How to use Asynchronous Agile estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

“Hybrid” Poker: The next generation poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Benefits of Hybrid Poker for Async session users . . . . . . . . . . . . . . . . . . . . . . . . 16

Hybrid Poker in Agile Poker for Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

What is Relative estimation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Why skip this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Is this method for you? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

How to use Relative Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

The Agile team’s comprehensive guide to acing estimations 2

Why skip this method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Is this method for you? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

How to use Bucket Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Planning Poker: The gold standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Prioritizing with Priority Planning Poker in the Agile Poker app . . . . . . . . . . . . . . 26

How do I make estimation work better? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Agile estimation is a team effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Download all cheat sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Appfire Apps that help with estimations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

The Agile team’s comprehensive guide to acing estimations 3

In this guide, we’ll discuss how to manage estimation in an Agile

The Agile team’s comprehensive guide to acing estimations 4

What is Agile estimation in

We’ll start with Planning Poker.

The Agile team’s comprehensive guide to acing estimations 5

What is Planning Poker?

Planning Poker is a gamified approach to estimating story point values. The

Teams can play Planning Poker both in-person and virtually, in a

Story points for Planning Poker

The Agile team’s comprehensive guide to acing estimations 6

Things to know when using story points for estimation:

• Story points do not measure the time spent on a story.

• Estimating in story points is typically faster than estimating time.

Benefits of using story points

Let’s review the benefits of using story points.

The Agile team’s comprehensive guide to acing estimations 7

As Jeff Sutherland observed, one CMMI level 5 company determined that

STORY POINTS REMAIN THE SAME FOR EVERYONE.

Estimating in story points allays team members’ fear of commitment. When

ELIMINATES THE NEED FOR FREQUENT RE-ESTIMATION.

STORY POINTS ENCOURAGE CROSS-FUNCTIONAL COLLABORATION.

The Agile team’s comprehensive guide to acing estimations 8

Because a story point is a single number, all team members need to

The team behavior takes precedence over individual preferences as

Now, back to Planning Poker.

Why use this method

Ultimately, having the opportunity to voice concerns and ask questions

Planning Poker also goes pretty fast!