Everything You Need To Know About Story Points In Jira

Estimating work in agile environments is rarely straightforward. Deadlines are rigid and often fail to reflect the real effort required, especially when accounting for distractions like Slack messages, meetings, or last-minute research.

That’s where story points come in. They help teams estimate effort, not time. When used well, story points improve sprint planning, increase predictability, and reduce stress across the board.

In this guide, you’ll learn what story points are, how to estimate them effectively, and how to use them inside Jira to build healthier, more predictable sprints.

What are story points in Scrum?

Story points are a unit of measure used in agile estimation to evaluate how much effort a user story requires. In scrum teams, this replaces traditional time estimates and focuses instead on relative estimation.

Teams typically assign story point values by considering three key factors:

• Complexity – How technically challenging is the work item?
  Example: Integrating with a third-party API that lacks clear documentation.
  
• Amount of work – How many tasks or subtasks are involved?
  Example: Renaming 200 image files and updating their metadata across environments.
  
• Uncertainty – How familiar is the development team with the problem or solution?
  Example: Debugging a rare issue that only happens under specific user roles.
  

In scrum, story points aren’t tied to a specific amount of time. Instead, they’re used to compare the relative size of stories. A story assigned 5 points should require more effort than a 2-point story, but less than an 8-point one.

Tip: Think of story points as an abstract measure of risk, effort, and unknowns; they are not hours or days. Over time, this becomes a powerful input for sprint planning, velocity tracking, and project management.

How to estimate a user story with story points?

There’s no universal method for estimating story points. Different scrum teams follow different approaches, depending on their experience, tech stack, and team structure. But the core goal is the same: estimate the effort, complexity, and uncertainty of a user story, not the exact amount of time.

Here are the most common estimation methods:

• Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) – The most popular option for agile estimation, especially in Jira. It limits choices and encourages teams to think in meaningful increments.
  Best for development-heavy teams and sprint execution.
• T-shirt sizes (XS, S, M, L, XL) – A relative scale often used during project planning or high-level backlog grooming. Works well for Epics and roadmap-level planning.
• Powers of 2 (1, 2, 4, 8, 16…) – A simplified approach that escalates faster than Fibonacci. Useful when dealing with larger initiatives or kanban-style workflows.

User Story Estimation Example

Story: “As a user, I want to reset my password via email.”

• For a team with reusable templates and email infrastructure already in place, this might be a 2-point story.
  

For a new team building everything from scratch, this could easily be a 5-pointer.

Story points scale with the experience of the team, the amount of work, and the tools available.

Pro tip: Don’t estimate alone. Include team members from engineering, product, and QA to capture multiple perspectives on complexity and blockers. It leads to more accurate estimations and healthier sprint planning sessions.

Story Points vs T-Shirt Sizes

Story points and T-shirt sizes are both used for relative estimation in agile teams, but they serve different purposes depending on the level of planning.

• T-shirt sizes (XS, S, M, L, XL) are helpful during early discussions, like when breaking down Epics or planning a roadmap. They work well when exact estimates aren’t necessary yet, and the team just needs a rough sense of size.
  Example: Epic = “Launch mobile onboarding v2” ? T-shirt size = “L”.
  
• Story points provide more granular, actionable effort estimates. They’re used at the user story level for sprint planning and workflow execution.
  Example: Story = “Design iOS welcome screen” ? Story points = 2.
  

The two methods aren’t interchangeable. Use T-shirt sizes during early product discussions. Convert those sizes into story point values during backlog refinement, when the full team reviews the amount of work, dependencies, and technical scope.

Best practice: Always estimate user stories during backlog refinement, not during sprint planning. Sprint planning is for deciding what to pull into the sprint, not for figuring out how long something might take.

Estimating Complex Stories

Not all user stories are created equal. Some involve obvious next steps; others require unknowns, experimentation, or coordination across teams. That’s when story point estimation becomes more art than science.

Let’s say the team is asked to “Implement OAuth2 login.”
At first glance, it might seem like a 5-point story.

But once you factor in:

• test coverage
  
• integration with existing auth systems
  
• edge-case handling
  
• documentation
  

…it may turn out to be an 8-pointer or even larger.

In these cases, forcing an estimate too early leads to underestimations and missed sprint goals. That’s why scrum teams often use a spike, a short, time-boxed task, to explore unknowns before committing to a full story estimate.

Tip: Use spikes for research-heavy or ambiguous work. Once the spike is complete, you can re-estimate the original story based on facts and not on guesses.

Refinement tip: If a story consistently scores high on complexity and uncertainty, consider breaking it down using the KISS principle. KISS stands for “Keep It Simple, Stupid” and makes you wonder if something needs to be as complex as it is.

Ask:

• Can this be split into subtasks or smaller work items?
  
• Is there a simpler way to deliver the same value?
  

Breaking large items into smaller, clearer pieces supports better workflow management, improves sprint planning, and reduces delivery risk.

How to use story points in Atlassian’s Jira?

In Jira, you can easily assign story points to user stories and subtasks, making estimation part of your team’s regular agile project workflow. While Jira supports story points out of the box for most issue types, some customization is needed to use them effectively across different layers of planning.

Add the Story Points Field to Epics

Jira does not display the story points field for epics by default. If you’re managing high-level planning or want to track estimates across multiple stories, you’ll need to configure this field manually. You can easily add a checkbox custom field to do the trick. Please note that you’ll need admin permissions to add and configure custom fields in Jira.

Steps:

1. Go to Jira Settings – Issues – Custom Fields
2. Search for “Story Points”
3. Add the field to your Epic issue screens
4. Ensure the correct permissions are in place for your team members to view and edit it

This setup lets you estimate both epics and individual stories. That’s useful when you need to align long-term planning with sprint-level execution.

Example: Assigning Story Points to Work Items

Let’s say you’re planning a new feature in your Jira project:

• Epic: “Create Smart Template integration for HR onboarding” – 13 story points
  
• Story: “Set up Slack notifications for new tasks” – 2 story points
  
• Subtask: “Configure automation rule” – 1 story point
  

This structure helps product owners, development teams, and project managers get a clear view of the amount of work across the board.

Tip: Only estimate what your team will actually deliver. Don’t overinflate by assigning points to tasks like meetings or code reviews unless they require substantial effort.

Estimating Collaboratively: Planning Poker in Jira

Assigning story points works best when it’s a team activity, not a solo estimate from one engineer or product owner. That’s why Planning Poker is a popular technique used by agile teams to run collaborative estimation sessions.

In Planning Poker, each team member privately selects a story point value for a specific work item. Once everyone votes, the numbers are revealed and the team discusses any differences. The process repeats until the group reaches a consensus.

Example:

Story: “Enable dark mode toggle”

• Developer 1: 2 points
  
• Developer 2: 3 points
  
• Developer 3: 5 points
  

A quick conversation reveals that one team member factored in responsive design challenges for mobile. The team agrees that it’s more complex than initially thought and settles on 3 story points.

This technique reduces bias, encourages team-wide input, and helps identify unknowns early in the estimation process.

Jira Integration Tip

You can run Planning Poker directly in Jira using built-in tools or marketplace apps. These tools sync Jira story points with the final vote and work seamlessly with your backlog and sprint planning workflows.

Best practice: Run Planning Poker sessions during refinement, not during sprint planning. Sprint planning should focus on choosing work, but not on the estimation of it.

What do you do with story points?

Sprint planning is not for estimating. Story point estimation should happen earlier—during refinement sessions, where the team and product manager align on scope, complexity, and priorities. By the time sprint planning begins, every story in the backlog should already have a point value.

Planning is about pulling the right amount of work, not debating effort. The only exception might be newly surfaced, urgent tasks that weren’t available during refinement. These can be estimated quickly if necessary, but that should remain rare.

Example:

Your development team has a velocity of 30 points. In sprint planning, you select:

• One 8-point epic
  
• Three 5-point stories
  
• Four 3-point stories
  Total: 29 story points
  

This allows your scrum team to work within a predictable delivery range while focusing on sprint execution.

Tracking progress in Jira

Once the sprint begins, Jira’s reports help track progress and highlight risks:

• Burndown chart – Tracks the remaining points during the sprint
  
• Velocity chart – Shows how many story points your team completes sprint over sprint
  
• Sprint report – Provides a summary of completed vs. committed work
  

These tools provide clear visibility for product managers, scrum masters, and the entire team, helping everyone plan better, avoid overcommitment, and track how story point values translate into real progress over time.

When you consistently estimate during refinement and track delivery through these reports, your team builds reliable agile estimation habits and your forecasts get better with every sprint.

Jira makes this easier by offering built-in agile project metrics that show how many points your development team has completed and how that compares to what was originally planned.

Example:

Your team committed to 35 points. You completed 32. That tells you two things:

• Your estimation was close to your team’s average velocity
  
• You might need to adjust the number of story points you commit to next time
  

Tracking story point metrics across sprints builds a reliable picture of what your team can handle, helping everyone from the product owner to QA set realistic expectations.

Add even more clarity to your stories with a checklist

Even with accurate story point estimation, things can still fall through the cracks, especially when it comes to Definition of Done, Acceptance Criteria, or small but essential tasks buried inside a story.

That’s where using a checklist makes a big difference.

With Jira Checklist, you can attach visible, structured checklists to your work items, giving your team a clear and consistent way to track completion at the task level. Whether you’re working with stories, subtasks, or even epics, checklists help reinforce shared expectations.

Examples of Where Checklists Help:

Definition of Done Checklist

• Code peer reviewed
  
• Unit tests written and passed
  
• No linting errors
  
• Jira status updated
  

Acceptance Criteria Checklist

• User sees confirmation message
  
• Data is saved to database
  
• Feature works on mobile and desktop
  
• No regression in signup flow
  

Using checklists, your team avoids assumptions and improves teamwork, time tracking, and workflow clarity. It’s especially useful for agile teams that want to reduce rework and improve automation.Pro-tip: Checklists are reusable. You can create a checklist template once and apply it across your entire Jira project. Combine them with story points, and you’ll create stronger stories and smoother sprints.

Add Smart Checklist to your Jira!

Try for free

Final thoughts: why story points matter in Jira

Story points help agile teams plan smarter, move faster, and deliver with more confidence. Instead of relying on vague time estimates, teams use story points to measure relative effort, which improves sprint planning, supports long-term forecasting, and reduces stress across the board.

Inside Jira, story points integrate directly into your workflow and reporting tools, including the burndown chart, velocity chart, sprint report, and burnup chart. When used consistently and estimated during refinement, not planning, they become a critical metric for healthy team performance.

Pairing story points with checklists, templates, and smart automation helps ensure that user stories, subtasks, and epics follow structured, repeatable processes. That’s how you build real predictability into your Jira projects.

• Use story points to align your product management strategy with real delivery capacity.
• Track progress over time to understand your team velocity.
• Add structure to your stories with tools like Smart Checklist and Smart Templates.

FAQ: Story Points in Jira

Can I use story points with epics in Jira?
Yes. While epics don’t include the story points field by default, you can add it using a custom field. This allows you to assign high-level estimates and align them with project planning goals.

Should I estimate during sprint planning?
No. Story point estimation should happen during refinement with the product owner and team. Sprint planning is only for selecting pre-estimated work from the backlog.

How do I assign story points to subtasks?
You can add the story points field to subtasks through Jira settings. Keep in mind that some reports (like the velocity chart) aggregate estimates only from stories, not subtasks.

What’s the best estimation method?
Most teams use the Fibonacci sequence (1, 2, 3, 5, 8…) because it’s simple and forces meaningful size differences. Some teams prefer T-shirt sizing or powers of 2 for high-level planning.

Can I use story points in kanban?
Yes. While kanban doesn’t use sprints, you can still estimate stories with story points to track effort and improve forecasting. Jira supports point-based metrics in both scrum and kanban boards.

How do I handle stories that change mid-sprint?
Use a sprint report to track any unfinished stories. You can re-estimate them during the next refinement session based on the updated scope or blockers.

Do story points affect automation or permissions in Jira?
You can build automation rules based on the number of story points. For example, trigger a rule if a story is larger than 13 points. Permissions to view or edit story points depend on your Jira role and project configuration.

Article by Viktoriia Golovtseva

Content Writer at TitanApps. Experienced Content Writer & Marketer, passionate about crafting strategic content that drives results and exploring the intersections of content and product marketing to create impactful campaigns. Dedicated to helping companies achieve their marketing goals through engaging storytelling and data-driven optimization.