Adding story points in Jira helps teams estimate work better. This guide shows you exactly how to set up the story points field, making your sprint planning clearer and your backlog estimates more accurate for smoother project management.
Ever felt like your Jira tasks are a bit… fuzzy? You know, when a “small” task ends up taking ages, or a “big” one is surprisingly quick? That’s where story points come in handy! They’re like a secret ingredient for making your team’s estimates much more reliable. But first, you need to get that story points field set up in Jira. Don’t worry if it sounds a bit techy; I’ll walk you through it step-by-step, just like I’d show you how to nock an arrow correctly. We’ll make sure your Jira board is ready to help you plan and deliver projects with confidence!
In Jira, story points are used to represent the effort, complexity, and uncertainty of a piece of work. They help teams move away from estimating in hours (which can be tricky and often inaccurate) and instead focus on relative sizing. This often leads to more consistent and predictable sprint planning.
Why Use Story Points in Jira?
Imagine trying to guess how long it takes an archer to hit a target without knowing their skill level or the wind conditions. It’s tough! Story points tackle a similar challenge in project management. Here’s why they’re a game-changer:
- Better Estimation: They provide a relative measure of effort, not a strict time commitment. This makes it easier for teams to agree on the size of tasks.
- Improved Predictability: Over time, teams can track how many story points they complete in a sprint (their “velocity”). This helps predict future capacity, leading to more reliable planning.
- Focus on Value: By abstracting away from hours, teams can focus more on delivering the actual value of a feature rather than getting bogged down in time-selling.
- Encourages Discussion: Estimating with story points often sparks valuable conversations within the team about the task’s scope, complexity, and potential risks.
Understanding Story Points: The Basics
Story points aren’t just random numbers. They usually follow a sequence, like the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…). Why this sequence? Because as estimates get larger, the uncertainty around them also increases. It’s easier to tell the difference between a 1-point task and a 2-point task than between a 20-point task and a 21-point task.
Here’s a common way teams interpret story points:
| Story Point Value | Typical Interpretation | Analogy (Archery Style!) |
|---|---|---|
| 1 | Very small, straightforward piece of work. Minimal effort, low complexity. | A perfect, easy shot at a close, stationary target. Almost automatic. |
| 2 | Small task. Requires a bit more effort or thought but is still quite manageable. | A good, solid shot at a slightly further target. Requires focus. |
| 3 | Medium task. Involves moderate effort, some complexity, or a few unknowns. | A challenging shot at a moving target or in gusty wind. Requires skill and planning. |
| 5 | Large task. Significant effort, several components, or a good amount of uncertainty. | A difficult shot at a very small target from a long distance. Many things can go wrong. |
| 8 | Very large task. Complex, time-consuming, or high risk. Might be broken down further. | A shot requiring a perfect release, expert aim, and perfect conditions, with a high chance of missing due to variables. |
| 13+ | Exceedingly large or complex. Almost always needs to be broken down into smaller, more manageable stories. | Trying to hit a tiny, fast-moving object while blindfolded and on a wobbly platform. Clearly needs a different approach! |
The key is that every team decides what these numbers mean for them. What one team calls a 3-point task might be a 5-point task for another, and that’s okay, as long as the team is consistent.
How to Add the Story Points Field in Jira
In Jira, story points are usually configured as a custom field. The exact steps can vary slightly depending on your Jira version (Cloud or Server/Data Center) and your project configuration, but the general process involves adding a numerical field to your issue types.
We’ll cover how to do this for Jira Cloud, as it’s the most common version for new setups. If you’re using Jira Server or Data Center, the administrative screens might look a little different, but the concepts are very similar.
Step 1: Access Jira Administration
First, you need administrative access to your Jira instance. If you don’t have it, you’ll need to ask your Jira administrator to perform these steps for you.
- Log in to your Jira instance.
- Click on the Settings icon (the gear icon) in the top right corner.
- Select Issues from the dropdown menu.
Step 2: Navigate to Custom Fields
In the Issues section, you’ll find various configuration options. We’re looking for “Custom fields.”
- On the left-hand sidebar, under “Fields,” click on Custom fields.
- This page lists all the custom fields currently set up in your Jira instance.
Step 3: Create a New Custom Field for Story Points
Now, we’ll create the field itself. Jira offers several field types, but for story points, a “Number field” is the most appropriate.
- Click the Create custom field button. This is usually located at the top right of the custom fields page.
- A modal window will appear, asking you to choose a field type. Scroll down or search for Number field.
- Click Next.
- Field Name: Enter “Story Points” (or “Story Point Estimate,” “Estimate,” etc. – choose a clear name).
- Description (Optional): You can add a description like “Estimated effort/complexity for a story using a non-time-based scale.” This helps other users understand its purpose.
- Click Create.
Step 4: Configure Screen Associations
After creating the field, Jira will prompt you to associate it with screens. Screens determine which fields appear when you create, view, or edit an issue. You need to add your new “Story Points” field to the relevant screens for your projects.
- Jira will show a list of screen schemes. You’ll need to select the ones that apply to the projects and issue types where you want to use story points.
- Commonly, you’ll want to add it to the “Create Issue Screen,” “View Issue Screen,” and “Edit Issue Screen” for your “Story,” “Task,” and “Bug” issue types, especially if you’re using Jira’s Software development workflows (like Scrum or Kanban).
- Look for the screen schemes associated with your Scrum or Kanban projects and tick the checkboxes next to the appropriate screens.
- Click Update.
Pro Tip: If you’re unsure which screen schemes to select, start with the most common ones for your team’s workflow (e.g., screens used for resolving issues). You can always adjust this later. A great resource for understanding Jira’s screen configurations is the official Atlassian Jira Cloud documentation on screens.
Step 5: Configure Field Context (Optional but Recommended)
While not strictly mandatory for basic functionality, configuring the field context makes your “Story Points” field behave as expected and prevents it from appearing where it shouldn’t.
- Go back to Settings > Issues > Custom fields.
- Find your newly created “Story Points” field.
- Click the ellipsis (
...) or “Configure” link next to it. - Select Configure context.
- Here, you can define which issue types and projects this field applies to. For example, you might want story points only for “Story” issue types within your “Scrum Project” and “Kanban Project.”
- Click Save or Add context.
Step 6: Add the Field to Your Board Configuration
For the story points to be visible and usable on your Kanban or Scrum board, you need to add them to the board’s column configuration.
- Navigate to your Jira project.
- Click on Board (or Backlog, depending on your Jira setup) in the left-hand sidebar.
- Click on the Board dropdown or the Configure button (often found at the top right of your board).
- Select Columns or Board Settings.
- Look for a section that allows you to customize the columns or card display. You should see an option to add or manage fields shown on cards.
- Add “Story Points” to the fields that appear on your cards.
- Save your changes.
Now, when you view your Jira board, you should see the “Story Points” field available. You can edit issues directly on the board and input your story point estimates.
Setting Up Jira for Story Point Estimation
Just adding the field isn’t the whole story. To make story points truly effective, you need to integrate them into your team’s workflow and estimation process. This involves getting your team on board and establishing clear guidelines.
1. Involve Your Team in the Process
This is crucial! Estimating is a team effort. Everyone on the team who works on the tasks should be involved in estimating.
- Training: Briefly explain what story points are and why the team is using them. Keep it simple and relatable.
- Reference Story: It’s incredibly helpful to agree on a “reference story.” This is a well-understood, representative story that you all agree is worth a certain number of story points (e.g., a typical 2-point story). This becomes your benchmark.
- Estimation Sessions: Dedicate time during your sprint planning or backlog grooming sessions for estimation.
2. Planning Poker (A Popular Estimation Technique)
Planning Poker is a fun and effective way to estimate story points as a team. Here’s how it generally works:
- The Facilitator: One person (often the Scrum Master or Product Owner) describes a user story or task from the backlog.
- Team Discussion: The team discusses the story, asking clarifying questions about requirements, complexity, and potential challenges.
- Individual Estimation: Each team member privately selects a card (or a virtual equivalent) representing their estimate of the story points for that task. A common set of cards uses the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (for “don’t know”).
- Reveal Estimates: Everyone reveals their chosen card simultaneously.
- Discussion and Re-estimation: If estimates are similar, you might be close! If there are wide variations (e.g., someone picked 2, and another picked 13), this highlights a difference in understanding. The individuals who picked the highest and lowest estimates explain their reasoning.
- Convergence: After discussion, the team re-estimates until consensus is reached or close enough.
You can find many online Planning Poker tools that integrate with Jira or work as standalone apps.
3. Calculating Velocity
Once your team starts completing sprints with story points, you can start tracking your velocity.
Velocity = Total Story Points Completed in a Sprint
By averaging the velocity over several sprints, you get a good idea of how much work your team can reliably complete in a future sprint. This is invaluable for forecasting and setting realistic sprint goals.
For example, if your last three sprints had a velocity of 25, 30, and 28 points, your average velocity is (25+30+28)/3 = 27.3 points. You might then aim for a sprint goal of around 27 story points for the next sprint.
Best Practices for Using Story Points
Here are some tips to make your story point system work even better:
- Keep it Relative: Always think about the effort compared to other stories, not in terms of absolute time.
- Break Down Large Stories: If a story is estimated at 8 points or more, it’s often too big. Break it down into smaller, more manageable stories that are easier to estimate and complete.
- Estimate as a Team: Ensure everyone participates. This builds shared understanding and ownership.
- Don’t Use Story Points for Time-Based Deadlines: Story points are for estimating effort and complexity, not for setting hard deadlines. If you need deadlines, use due dates, but understand they are separate from your story point estimates.
- Review and Adapt: Periodically review your estimation process. Are your estimates becoming more accurate? Is your velocity predictable? Adjust your approach as needed.
- Don’t Estimate Individual Tasks: For epics or larger features, you might estimate the stories within them. For very small tasks (like sub-tasks), estimating might be overkill.
Troubleshooting Common Jira Story Points Issues
Even with the best setup, you might run into snags. Here are a few common issues and how to tackle them:
| Problem | Possible Solution |
|---|---|
| Story Points field not visible on Jira board. | Ensure you’ve added the “Story Points” custom field to the screens associated with your project’s Create, Edit, and View Issue operations. Also, check your board’s configuration to ensure the field is set to display on cards. |
| Team members can’t edit the Story Points field. | Verify that the user has the necessary Jira permissions to edit issues. If it’s a permission scheme issue, consult your Jira administrator. |
| Story Points are appearing on unintended issue types or projects. | This is usually a context issue. Go back to Custom Fields, find “Story Points,” configure context, and set it to apply only to the specific issue types and projects where you want it used. |
| Estimates are wildly inconsistent sprint after sprint. | This might indicate a need for better team alignment on what story points mean. Revisit your reference story, conduct more thorough backlog grooming, and practice Planning Poker more consistently. It could also mean tasks are too large and need breaking down. |
| Jira doesn’t seem to have a “Story Points” field type. | Jira typically uses a “Number field” and you name it “Story Points.” There isn’t a built-in field type labeled “Story Points” out-of-the-box for non-Jira Software-specific setups, but the “Number field” serves the purpose perfectly. |
Frequently Asked Questions about Jira Story Points
Q1: What is the difference between Story Points and Hours in Jira?
A1: Hours estimate the time a task is expected to take, which can be influenced by individual speed and distractions. Story points estimate the effort, complexity, and uncertainty relative to other tasks, leading to more consistent team-wide planning.
Q2: Do all teams need to use story points?
A2: Not necessarily. Story points are most effective for teams practicing agile methodologies like Scrum or Kanban. Teams with very predictable, task-oriented work might find time-based estimates sufficient. However, they offer significant benefits for most software development and project teams.