Name: How to Run your first Planning Poker session in Jira
Uploaded: 2025-03-19T13:22:44.811Z
Description: Learn how to run your first Planning Poker meeting. Step-by-step guide to enhance agile estimation and improve team collaboration.

large_Post-Its-Lots-of-them.webp

medium_Post-Its-Lots-of-them.webp

small_Post-Its-Lots-of-them.webp

thumbnail_Post-Its-Lots-of-them.webp

Post-Its-Lots-of-them.webp

Learn how to run your first Planning Poker meeting. Step-by-step guide to enhance agile estimation and improve team collaboration.

SmartGuess setup with a Fibonaccy approximation card deck

SmartGuess-Fibonaccy-Approximation.jpg

After a couple of refinement meetings, you might see a reason to remove or add cards - but for now - keep it simple and use the default card deck.

 ## Step 4. Before giving an Estimate - Explain each Story Clearly 
Before estimating a story, go through the story and clarify who your target users are, their motivations, purpose of story, it's expected outcome, etc. Encourage team members to ask questions, discuss implementation options and share insights. 

If a story lacks sufficient details and some aspect needs further clarification, delay estimation until the story is ready for estimation. Check out [Definition of Ready](https://www.atlassian.com/agile/project-management/definition-of-ready) for more information.

## Step 5. How to Estimate the First Story - Establishing a reference point
Estimating the first story can be challenging since there is no prior reference for comparison. To establish a reference point, start by allowing the team to identifying the smallest story in the backlog. Once the smallest story is found, assign it a low story point value, such as 2 or 3.

Avoid assigning a value as low as 0.5 or 1 for the reference story, unless you are certain you will not see a smaller story in your backlog. This ensures that when the team encounters an even smaller story later, lower values (e.g., 0.5 or 1) remain available.

From now on, this story serves as a “reference point” for future estimations. By establishing this baseline, the team can compare subsequent stories to it, ensuring consistent and relative estimation throughout the backlog.

It’s considered a best practice to establish a reference story for each story point value (e.g., 2, 3, 5, 8) over time. Doing so provides the team with concrete examples for different levels of complexity and effort. When a new story is being estimated, the team can compare it to these established reference stories to determine the most appropriate story point value. This practice helps maintain consistency in estimations and improves accuracy as the team builds a shared understanding of what each story point value represents.

For example, if the reference story is two story points, the team can compare new stories against it: 
- If a new story seems to require roughly twice as much effort, assigning five-story points, might be appropriate.
- If a story seems to require more effort than five-story points, assigning eight-story points, or more should be considered.

As the team assigns story point values to more stories, they quickly develop a good feeling for matching story points to user stories based on their complexity and expected effort to implement. 

## Step 6. Voting and Discussion
1. Each team member privately selects a card that represents their estimate.
2. The Scrum Master reveals all estimates when everyone has selected.
3. If estimates vary significantly, discuss the differences. Team members with high and low estimates should explain their reasoning.
4. Repeat the estimation until consensus is reached or use the highest estimate as a precautionary approach.

With Smart Guess here is how it's done:

Jira-Backlog-3-2.png

## Step 7. Save the estimate and Move Forward
Once the team reaches an agreement, save the estimate and continue until you have covered all relevant backlog items in the session.

## Best Practices when using Relative Estimates

### Use estimates for: 
- **Release Planning:** Forecasting which features can be delivered by specific dates, aiding in setting realistic release schedules.
- **Backlog Prioritization:** Determining the order in which tasks or features should are implemented based on their estimated effort and value.
- **Decision-Making:** On how you implement your solution when different solution options, effort and value, are present.
- **Capacity Planning:** Assessing the team’s workload capacity to ensure they are not overcommitted.
- **Identifying High-Risk Items:** Highlighting important tasks with high effort to recognize potential risks or complexities that may need further analysis and potential scope cutting. 

### Don't use estimates to:
- **Compare teams performance:** One team's velocity is inherently not comparable to another team's velocity. Velocity is a relative measure that only holds meaning within the team that produces it.
- **Assess Individual Performance:** Using estimates to judge individual contributions can create unhealthy competition and undermine collaboration. Often the most valuable team member is the person who is sharing his knowledge and knowhow generously.
- **Push Estimates Down:** [Forcing teams to commit to lower estimates](/blog/challenging-agile-estimates/) can lead to unrealistic expectations, compromised quality and toxic working environment for team members.
- **Setting Fixed Deadlines:** Treating estimates as exact timelines can result in [undue pressure and toxic development environment](https://www.reddit.com/r/programming/comments/17cha28/comment/k5rvhqc/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)


By following these steps, you’ll make your Planning Poker refinement sessions more effective, leading to better planning and alignment within your team. Happy estimating!



How to Run Your First Planning Poker meeting: A Step-by-Step Guide

Flow Metrics shows leadership what you actually do: identify bottlenecks, improve predictability, and protect delivery. Turn invisible work into measurable results.
> "Finally, data that proves what I've been saying all along."

*Free trial available — no credit card needed 💡*  

Stop Defending Your Value. Start Proving It.

Turn Jira data into insights you can act on. Spot bottlenecks, track cycle time, and forecast delivery with confidence — all inside Jira.  

> “Smart Guess gave us instant visibility into our process. It’s the first time we’ve felt in control of delivery.”  

*Now available with a free trial — no budget approval needed 🚀*

See Your Team’s Flow Clearly.

Make cycle time, throughput, and WIP visible without spreadsheets or consultants. Smart Guess Flow Analytics shows where work really gets stuck — so you can act early.  

> “We cut weeks off our cycle time after seeing where work was really getting stuck.”  

*Free 30-day trial — see your flow in action 🔍*  

Uncover Bottlenecks Before They Hurt Delivery

Try One-Click Planning Poker you run from the Jira Backlog and you will never look back.

"After trying many tools in Jira, we landed on Smart Guess. It's the best app ❤️ we've ever used!"

Now available for free — no budget approval needed! 🚀


Transform your Planning Poker

Run one-click Planning Poker directly from the Jira Backlog and never look back. Estimate faster, collaborate better, and keep everyone aligned.  

> “After trying many tools in Jira, we landed on Smart Guess. It's the best app ❤️ we've ever used!”  

*Now available for free — no budget approval needed 🚀*  

Transform Your Planning Poker

Every missed deadline has a cause. Every blown estimate has a reason. 

But without connecting the dots across sprints, you're experiencing the same problems over and over.

We'd been underestimating integrations for 18 months. It was obvious once we could finally see it.

How Many Sprints Before You Spot the Pattern?

When stakeholders push for aggressive timelines, you feel the risk. 

But _"I think this is too ambitious"_ doesn't win arguments. Data does.

_"For the first time, I could show leadership exactly why their deadline was unrealistic—with numbers, not opinions."_

Turn intuition into evidence —free trial available 📊

You Know It's a Bad Estimate. But Can You Prove It?

Two 5-point stories. One takes 2 days, the other takes 2 weeks. Your team estimated them the same—but something made them wildly different. 

Without visibility into what, you'll keep guessing.

_"We discovered our 'quick fixes' were actually taking longer than new features."_

Stop guessing, start knowing—free 30-day trial 💡

Same Story Points. Different Outcomes. Why?

Dozens of estimation sessions per team. Hundreds of data points. All of it disappears the moment the meeting ends. What if that data could actually improve your predictions?

_"Years of Planning Poker sessions—finally doing something useful."_

Turn estimation history into foresight—free trial 🎯

You Run Planning Poker Every Sprint. What Happens to That Data?

Stakeholders add urgent work mid-sprint. You know it hurts delivery—but without concrete data, you can't quantify the damage or push back effectively.

_"Now I can show exactly how much longer planned work takes when we interrupt it with urgent requests. The conversations have changed completely."_

Quantify the true cost of interruptions—free trial  🎯

How Much Did That 'Quick Request' Actually Cost?

Story points tell you relative size. They don't tell you when something will ship. The gap between estimation and prediction is where promises break.

_"We went from 'probably next month' to '85% confidence by March 15th.' Leadership finally trusts our timelines."_

From estimates to predictions—start free 📅

Your Team Estimates. But Can You Actually Predict?

Issues sit in "In Review" for days. Blockers hide in "Waiting for Info" for weeks. 

Without visibility into time spent per status, you're managing blind. 

_"We discovered issues were spending 60% of their lifecycle waiting—not being worked on."_

See the truth about your workflow—free trial 🔍

Where Does Your Team's Time Actually Go?

Every retrospective, the same question: _"Why didn't we finish?"_ Without time-in-status data, you're debating opinions instead of analyzing facts.

_"Turns out our bottleneck wasn't development—it was code review. We never would have known without the data."_

Find your real bottlenecks—start free 📊

Stop Guessing Why Sprints Slip

Every process has blind spots. Time In Status reveals the delays your workflow has normalized—the ones nobody questions anymore.

_"At sprint end, our 'quick QA pass' was averaging 3+ days. Nobody realized until we measured it."_

Uncover what you've been missing—free trial 💡

It's Been In QA For How Long?

Every status change in Jira is a data point. But without analysis, it's just noise. 

_"We identified that issues with external dependencies spent 3x longer in 'Blocked' than internal work.\"_

Make your data work for you—free 30-day trial 🎯

Turn Status History Into Process Insights

using contentList for cta messages


https://marketplace.atlassian.com/apps/1225496/

Paid app

nav-try-button

SG-full-color-black.svg

SG-full-color-blue.svg

SG-logo-black-07.svg

SG-logo-color-05-MarketPlace.svg

SG-logo-white-06.svg

SG-full-color-white.svg

See what's unpredictable. Understand why. Fix it. AI-guided insights help you spot bottlenecks, reduce variation, and make estimates that actually hold up.

Estimate smarter together. Real-time collaboration meets historical data. AI-powered insights help your team calibrate estimates based on what actually happened, not just gut feeling.

How to Run your first Planning Poker session in Jira

Story Points 101

Topics covered in the series

Popular posts

Explore More Ways to Improve Delivery

Flow Intelligence

Predictive Planning Poker