Tools for Jira
Tools for monday.com
According to Atlassian’s State of Teams 2025 report, teams lose 27% of the workweek to searching for information and tracking work status – a problem that vague, time-based estimates make worse. 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.
It is written for scrum masters, product owners, and delivery managers who plan work in Jira and want more accurate sprints.
Key Takeaways
- Story points measure the effort, complexity, and uncertainty of a user story, not time, so agile teams can plan sprints more predictably.
- The Fibonacci sequence is the most common story point scale in Jira because it forces meaningful size differences between estimates.
- Estimate story points during backlog refinement, not during sprint planning. Sprint planning is for pulling pre-estimated work into the sprint.
- Jira hides the story points field on Epics by default, so admins need to add it as a custom field to enable estimation.
- Pairing story points with Smart Checklist keeps Definition of Done and Acceptance Criteria visible inside every issue, reducing rework across sprints.
What Are Story Points in Jira?
Definition
Story points are a unit of relative estimation used by agile teams to size the effort behind a user story. Rather than measuring time, they capture complexity, workload, and uncertainty in a single number. In Jira, story points feed sprint planning, velocity tracking, and forecasting, giving teams a more reliable way to plan than deadline-based estimates.
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.
Pro-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.
How does story point estimation look for a real user story?
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.
| Criteria | Story points | T-shirt sizes | Notes |
|---|---|---|---|
| Granularity | Fine (1, 2, 3, 5, 8, 13...) | Coarse (XS, S, M, L, XL) | Story points force more precise trade-offs. |
| Best stage | Backlog refinement, sprint planning | Roadmap planning, Epic breakdown | Different stages of the same project. |
| Estimation level | User stories and subtasks | Epics and initiatives | The two methods complement each other. |
| Best used for | Sprint execution and velocity tracking | High-level scoping conversations | Choose based on the audience and the decision at hand. |
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.
How do you estimate stories with unknowns or unclear scope?
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.
Pro-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. Attaching a checklist template from Smart Checklist to the split stories keeps the shared acceptance rules visible in every child issue, so nothing quietly gets dropped during the split.
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:
- Go to Jira Settings – Issues – Custom Fields
- Search for “Story Points”
- Add the field to your Epic issue screens
- 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.
How do story points scale across Epics, stories, and subtasks?
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. Teams that create these hierarchies from scratch every sprint often lean on Smart Templates from TitanApps to keep the Epic/story/subtask structure consistent, so estimation stays comparable across sprints instead of drifting with each new project.
Note
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.
Can you run Planning Poker directly in Jira?
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.
Which Jira reports show story point progress during a sprint?
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.
How does a checklist reinforce story point estimates?
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.
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.
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.
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. A Jira admin needs to add the Story Points field to the Epic issue screen through Jira Settings ? Issues ? Custom Fields, then confirm view and edit permissions for the right roles. Once the field is live, teams can compare Epic-level totals to the sum of the underlying story estimates and spot Epics that are drifting out of scope. Teams working across multiple projects often standardize this setup through Smart Templates so every new Epic launches with the same field structure and estimation habits.
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. Estimating during sprint planning mixes two very different conversations – what to build and how big it is – and both suffer. Move estimation into a dedicated backlog refinement session at least a few days ahead of planning. That gives the team time to research spikes, split large stories, and update Acceptance Criteria before commitments are made. Sprint planning then becomes a fast, focused conversation about capacity and priorities.
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. If you estimate at the subtask level, decide upfront whether the parent story’s estimate is the sum of its subtasks or an independent, higher-level number – and stick to that rule. Mixing both quietly inflates velocity and breaks forecasting. Many teams keep parent-story estimation as the source of truth and use Smart Checklist items instead of subtasks for the smaller steps inside a story, which keeps the reporting model clean.
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. The right choice depends on the stage of planning and the audience. Fibonacci works best inside development teams estimating stories they will actually deliver in the next few sprints. T-shirt sizes work better in early roadmap discussions with product leadership, where exact numbers would create false precision. Powers of 2 sit somewhere in between and suit teams dealing with a mix of small tasks and much larger initiatives. Whichever scale you pick, use it consistently – switching mid-project undermines velocity data.
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. Kanban teams typically use story points to measure throughput per week or per cycle instead of per sprint. Combined with cycle time, points give a clearer picture of both how much work flows through the system and how complex that work is. A steady story-point throughput with fluctuating cycle time usually signals that stories are similar in size but blocked by external dependencies – a useful diagnostic that pure ticket counts would miss.
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. Resist the temptation to re-estimate mid-sprint, even when the scope expands. Instead, close the original story at its current point value, note the change, and create a follow-up story with a fresh estimate for the remaining work. This keeps velocity honest and makes it easier to see how often scope creep is eating capacity. Pair this practice with Smart Checklist items on the original story so the exact steps that were and weren’t completed are traceable when the follow-up story is written.
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. Common automations include flagging oversized stories for refinement, alerting the product owner when a sprint’s total commitment crosses the team’s average velocity, or auto-labeling stories that need to be split. On the permissions side, the Story Points field follows the same field-level security model as any other custom field, so if a role can’t see it on the screen, they can’t include it in JQL either. Review both the screen configuration and the field context when troubleshooting missing points.
