Everything You Need To Know About Story Points In Jira
Accurately estimating work in agile teams is one of the most important — and most challenging — aspects of project planning. While deadlines often demand fixed dates, real-world development involves uncertainty, distractions, and shifting priorities.
That’s why many Jira teams rely on story points. Instead of estimating in hours or days, story points help your team gauge relative effort. They take complexity, uncertainty, and workload into account — giving product owners, developers, and scrum masters a better foundation for sprint planning and forecasting.
In this guide, we’ll break down what story points are, how to estimate them effectively, and how to use them inside Jira Software to improve workflows, reduce overcommitment, and track team progress across sprints.
What Are Story Points in Scrum?
Story points are a relative unit of measure used by agile teams — especially scrum teams — to estimate the effort required to complete a user story or work item in Jira.
Unlike time-based estimates, story points focus on:
- Complexity – How technically challenging is the work?
- Amount of work – How much needs to be done?
- Uncertainty – How familiar is the team with the task?
For example:
- Integrating with a new third-party API might be more complex than adding validation to an existing form.
- Writing tests for a known workflow might involve less uncertainty than debugging a production issue that only occurs for specific user roles.
Story points aren’t tied to a fixed number of hours. Instead, they help the team compare tasks in relation to one another. A 5-point story should require more effort than a 2-point one, but less than an 8-point task.
Think of story points as a combination of risk, complexity, and effort — not time. This makes them ideal for agile estimation, velocity tracking, and long-term project planning.
Over time, your team will calibrate what each point value means. That’s how story points support predictable delivery and more confident sprint commitments.
How to Estimate a User Story With Story Points
There’s no universal formula for story point estimation. Each scrum team builds its own approach based on experience, tools, and technical context. The main goal is always the same: estimate how much effort, complexity, and uncertainty a user story involves — not the number of hours it will take.
Here are three popular methods used in agile teams and Jira projects:
- Fibonacci Sequence (1, 2, 3, 5, 8, 13…)
This is the most widely used method for story point estimation in Jira. It forces teams to choose meaningful jumps in effort and avoids false precision. Best suited for development teams during sprint planning or execution. - T-Shirt Sizes (XS, S, M, L, XL)
Ideal for early-stage planning or roadmap discussions when stories haven’t been broken down yet. Useful for Epics and backlog items where rough sizing is enough. - Powers of 2 (1, 2, 4, 8, 16…)
A simpler scale that increases more aggressively. Helps when estimating larger features or working in kanban systems without sprints.
Example: Estimating a User Story
Story: “As a user, I want to reset my password via email.”
- For a team with existing email templates and infrastructure, this might be a 2-point story.
- For a team starting from scratch or integrating a new third-party service, it could be a 5-pointer.
Story points adapt to each team’s skill level and context. That’s what makes them powerful for agile project management.
Estimation Tip:
Always involve the whole team — including developers, QA, and the product owner — when estimating stories. Group discussion surfaces unknowns, improves accuracy, and keeps everyone aligned on complexity and scope.
Story Points vs. T-Shirt Sizes
Both story points and T-shirt sizes are tools for relative estimation, but they serve different purposes in the agile planning process.
T-shirt sizes (XS, S, M, L, XL) work well in early-stage conversations — when the team is scoping out a roadmap, breaking down Epics, or prioritizing large work items. They provide a quick sense of effort without requiring precision.
Example: Epic – “Redesign mobile onboarding flow” → T-shirt size = L
Story points, on the other hand, provide a more detailed estimate for sprint-level planning. They’re used for refining user stories once the team understands the technical details and expected workload.
Example: Story – “Implement the welcome screen UI” → Story points = 3
T-shirt sizes are directional; story points are actionable.
Best practice:
Estimate with T-shirt sizes when exploring the backlog or building a project roadmap. Convert those sizes into story points during backlog refinement, once stories are ready for the team to commit to during a sprint.
Sprint planning should focus on pulling pre-estimated work, not on discussing how much effort it will take. That work should already be done.
Estimating Complex Stories
Some user stories are straightforward. Others involve unknowns, dependencies, or system-wide implications that make estimation trickier.
Take the story: “Enable OAuth2 login.”
At first, it might seem like a 5-point effort. But once you account for integration with internal auth systems, test coverage, edge-case handling, and documentation — the complexity increases. What seemed like a medium story could turn into an 8-pointer or more.
Instead of guessing, many agile teams use a spike — a short, time-boxed research task — to explore the work before committing to an estimate. Spikes don’t deliver value to users directly but provide clarity for upcoming work.
Tip: Use spikes when a story has high uncertainty or potential blockers. Re-estimate after the spike is completed and the team has more information.
Also, if a story keeps scoring high across effort, complexity, and uncertainty, it might be too big.
Ask:
- Can the story be broken into smaller work items?
- Is there a simpler path to deliver the same value?
Splitting large or ambiguous work helps scrum teams reduce delivery risk, improve sprint planning, and build a more predictable workflow.
How to Use Story Points in Jira
Story points become most useful when integrated directly into your team’s Jira project. Estimating effort and tracking progress across user stories, epics, and subtasks helps teams stay aligned and improve delivery over time.
Add the Story Points Field to Epics
By default, Jira Software doesn’t show the Story Points field on epics. If your team does high-level project planning or wants to align epics with sprint estimates, you’ll need to add this field manually.
To do this, you’ll need Jira admin permissions:
- Go to Jira Settings → Issues → Custom Fields
- Search for “Story Points”
- Click “Screens” to add it to the Epic issue type
- Ensure your team can view and edit the field
Once configured, you can estimate epics, stories, and even subtasks, making it easier to connect backlog planning to sprint execution.
Example: Estimating Work Items in Jira
Say you’re planning a new feature rollout:
- Epic: “HR Onboarding Workflow” → 13 story points
- Story: “Set up Slack notifications” → 3 story points
- Subtask: “Configure automation rule” → 1 story point
Each level of work gets an estimate, and Jira’s built-in reports (like burndown charts and velocity charts) use these numbers to track progress.
Tip: Estimate only what reflects real effort. Don’t assign points to low-effort activities like meetings or syncing unless they require deliverables.
Estimating Collaboratively: Planning Poker in Jira
Estimation works best when it’s a shared activity. Relying on one developer or a product owner to assign story points alone often leads to bias or missed complexities. That’s why many scrum teams use Planning Poker—a structured, collaborative approach to estimating work.
In Planning Poker, each team member selects a story point value privately. When all votes are revealed, the team discusses differences and aligns on a final estimate.
Example: Estimating as a Team
Story: “Add dark mode toggle”
- Developer A: 2 points
- Developer B: 3 points
- Developer C: 5 points
A short discussion reveals Developer C considered additional responsive design work. The team agrees it’s more complex than it looks and settles on 3 story points.
This process ensures:
- Every perspective is heard (dev, QA, product)
- Risks and unknowns are uncovered early
- The final estimate reflects team effort, not one opinion
How to Run Planning Poker in Jira
Jira Software supports Planning Poker through Marketplace add-ons or integrations. These tools sync point values directly with your Jira backlog and support estimation during refinement sessions.
Best practice: Estimate stories during refinement, not during sprint planning. Planning Poker helps you assign story points in advance, so the team can focus on priorities during sprint planning—not debate estimates.
What Do You Do With Story Points?
Once your team has assigned story points during refinement, use them to guide sprint planning—but don’t confuse the two. Sprint planning is about choosing the right amount of pre-estimated work to fit into the sprint. It’s not the time to estimate.
During planning, you look at your team’s velocity—the average number of story points completed per sprint—and select backlog items that match that number.
Example:
If your scrum team completes about 30 story points per sprint, you might pull:
- 1 Epic (8 points)
- 3 User stories (5 points each)
- 4 Small tasks (2–3 points each)
→ Total: ~29–30 points
This approach gives you predictability. You avoid overcommitment and create space to handle blockers or unexpected work.
The only time to estimate during sprint planning is if a last-minute work item surfaces that wasn’t reviewed during refinement. Estimate it quickly and keep this the exception—not the norm.
Tip: Keep your backlog clean and estimated in advance. This lets sprint planning focus on delivery, not discussions.
Tracking Progress in Jira
Once your sprint begins, Jira provides powerful tools to track how your team performs against the estimated story points.
Here are the key agile metrics to monitor:
- Burndown Chart – Shows how many story points remain in the sprint and whether the team is on track.
- Velocity Chart – Displays the number of points completed across multiple sprints. This helps forecast how much work the team can take on.
- Sprint Report – Summarizes planned vs. delivered work. It highlights what was completed, what carried over, and where blockers may have appeared.
These metrics are available in Jira Software and give product owners, scrum masters, and team leads clarity on progress, scope, and delivery risk.
Example:
If your team committed to 35 story points and completed 32, that tells you:
- Your estimates were close to your actual capacity.
- You might need to adjust expectations slightly next sprint.
Tracking story point estimation over time builds accuracy and improves your team's forecasting. It also supports better retrospectives by showing where delivery fell short or exceeded expectations.
Pro tip: Teams that consistently track velocity and deliver close to their committed story points build stakeholder trust and improve long-term planning across the project roadmap.
Add Even More Clarity With a Checklist
Even if your team uses story points effectively, it’s still easy to miss steps—especially when it comes to things like Definition of Done or Acceptance Criteria.
That’s where checklists help. Instead of relying on memory or comments, you can attach structured checklists to Jira issues. This makes your workflow more consistent and transparent for the entire scrum team.
For example:
- Definition of Done Checklist
Ensure every story meets your team's quality standards.
Include steps like: code peer review, unit tests passed, linting cleared, and Jira status updated. - Acceptance Criteria Checklist
Track what the user story is supposed to achieve.
Example items: data saved, mobile compatibility verified, or success message displayed.
Checklists are especially useful for agile teams managing many stories across sprints, helping reduce rework and improve collaboration across team members, including QA, developers, and product owners.
If you’re using a checklist add-on like Smart Checklist, you can also:
- Reuse templates across your Jira project
- Assign checklist items to individual team members
- Add due dates, priorities, and even trigger automation rules
That means fewer subtasks, better tracking, and faster sprint execution—without cluttering your kanban or scrum board.
For more details check out Smart Checklist for Jira.
Tip: Use checklist templates alongside story points to create more structured, reliable stories. It makes sprint planning easier and increases delivery confidence.
Final Thoughts: Why Story Points Matter in Jira
Story points help agile teams focus on effort, not hours. When used consistently, they bring structure to sprint planning, support long-term roadmap forecasting, and reduce stress across the board.
Inside Jira Software, you can:
- Estimate work items with story points
- Track team progress using built-in reports like the burndown chart and velocity chart
- Improve delivery confidence through clear, consistent relative estimation
Teams that estimate during refinement (not sprint planning), use Planning Poker, and update their backlog regularly get the most value. Pairing story points with tools like checklists, templates, and automation leads to stronger workflow structure and healthier delivery habits.
Use story points to:
- Align your product owner and team on effort
- Create realistic project planning goals
- Improve visibility across stakeholders
- Reduce missed steps using checklist integrations
- Track delivery velocity and forecast smarter
Over time, this helps your team build trust, ship more predictably, and keep agile estimation grounded in reality—not guesswork.
FAQ: Story Points in Jira
Q1: Can I use story points with epics in Jira?
Yes. By default, the story points field is hidden for epics. You can enable it by adding a custom field through Jira settings. This helps you assign story points at both epic and story levels, useful for roadmap planning and tracking relative effort.
Q2: Should I estimate during sprint planning?
No. Story point estimation should happen during refinement sessions, where the product owner and team align on scope and complexity. Sprint planning is for selecting already-estimated backlog items — not for debating their size.
Q3: How do I assign story points to subtasks?
You can add the story points field to subtasks through Jira settings. Keep in mind, however, that most metrics and reports like the velocity chart only count points from stories — not subtasks. Still, assigning values to subtasks can help estimate detailed effort.
Q4: What’s the best method for estimating story points?
Most scrum teams use the Fibonacci sequence (1, 2, 3, 5, 8…) because it introduces meaningful gaps between values and avoids over-precision. Some teams use T-shirt sizes or powers of 2 at the epic level. Choose a method and stay consistent across the team.
Q5: Can I use story points in kanban?
Yes. Even though kanban doesn’t use time-boxed sprints, you can still use story points to estimate effort and support workflow forecasting. Jira supports agile estimation across both scrum and kanban boards.
Q6: How do I handle stories that change mid-sprint?
Use the sprint report to review any unfinished work. If a story changes in scope, re-estimate it during the next refinement session. It’s okay to adjust the number of story points if the original assumptions no longer apply.
Q7: Do story points affect automation or permissions in Jira?
Yes. You can build Jira automation rules based on the story point value (e.g., flag stories larger than 13 points). Permissions to view or edit story points depend on your project configuration and user role.
For more details check out Smart Checklist for Jira.
Was this helpful?
Thanks!
Viktoriia Golovtseva _TitanApps_
About this author
Senior Content Writer & Marketer
Railsware
1 accepted answer
2 comments