Jira Pack guide

Explore

Jira Pack guide

Additional resources

How to use story points in Jira and reporting with Coda's Jira Pack [2024]

Before we get into how to use story points in Jira, here’s a quick rundown on what story points are and how to estimate them. See what some industry experts said about improving points estimates from

this Atlassian webinar⁠

in 2020. At the end of the article, I’ll share some story point estimation exercises you team can try to estimate story points for your Jira project. What the video tutorial below for a visual walkthrough:

⁠

What are story points in agile?

A story point is simply an estimate on the overall effort to complete something in your product backlog. Traditional software teams use to do estimate overall effort with time (e.g. this UI design will take 10 hours). Teams that practice agile have moved to the more abstract story point method because it encourages teams to make better estimates about the difficulty of a task.

If you are new to story points you might be asking: How many hours is 5 story points? or How many story points is 5 hours? You can calculate this based on the historical effort it took to complete a item in your backlog. For instance, if a 10-story point item on your backlog took 20 hours to complete, you can estimate that a 5-story point item would take 10 hours to complete.

⁠

Example of issues with story points in Jira

How do you figure out how many hours a story point should be?

A popular exercise for coming up with a benchmark for story points for your team is

planning poker⁠

. In this exercise, you pick one item from your product backlog and have everyone enter what they think the overall effort to complete that item would be in story points. You unhide everyone’s answers and discuss why there’s a variance in answers and come to a conclusion on what the story point estimate is. Once your engineering, design, and product teams align on what the story points would be for adding additional endpoints to your API would be, for instance, they will be able to benchmark that item against future items on the backlog.

What are story points in Jira and how do you use them?

So your team is bought into using story points on your next sprint in Jira. Great! To add story points to your tasks, stories, and bugs in Jira, you have to turn on the Story Point setting in your company-managed or team-managed project. I’ll walk you step-by-step on how to do this below:

Step 1: Turn on story points in your board settings

You need to be and admin for your Jira workspace to turn on the Story Points settings. For a company-managed project, click on the 3 dots in the top-right of your Backlog board and click Configure board. Under the Estimation setting, you’ll see a dropdown for the Estimation method. Change that to “Story Points.”

On a team-managed project, click on Project settings → Features. Under the Estimation panel, turn the toggle to on and make sure the Story Points radio button is selected. This is what the settings look like on both company-managed and team-managed projects:

⁠

Story Points setting on company-managed project

⁠

Story Points setting on team-managed project

Step 2: Click on an issue’s gray bubble on the Backlog to set the issue’s Story Points

Typically you’ll add Story Points to issues when you’re planning the next sprint with your teammates. The person who is doing the actual work should be present when these Story Point estimates are created in Jira. You should be in the Backlog view of your project to make entering the Story Points quicker. Next to each issue, you’ll see a small gray bubble. When you click on that bubble, you can set the Story Points for a story, sub-task, and bug.

⁠

If you are in another view of your project (e.g. Timeline, Active Sprints, etc.), you can still edit the Story Points by clicking on the issue and going into the issue detail view. If the issue doesn’t have any Story Points assigned to it, you will see the Story Points field in the More fields panel on the issue detail view:

⁠

An important caveat for team-managed projects is that the Story Points field is actually called Story points estimate (see screenshot below). This may be important for when you are doing burndown charts or writing JQL queries because you need to use the right field name.

⁠

Step 3: Reporting on Story Points for your sprint and managing your team’s capacity

A quick way to get the total Story Points for issues that are Not Started, In Progress, and Completed is to look at the 3 bubbles at the top of your Sprint (in the Backlog view):

⁠

The first number is the total number of Story Points for Not Started issues. The second and third numbers are the total number of Story Points for In Progress and Completed issues, respectively. There is an issue with how Jira sums up these Story Points which I’ll describe in the section below. For now, it’s a good indicator for how your Sprint is progressing.

To see how many Story Points each Assignee is working on for your sprint, you can click on the 3 dots next to the avatars near the top of the sprint in Jira. By default, Jira does not include sub-tasks in the Story Points calculation, so you can click on that toggle to show total Story Points on sub-tasks that have Assignees:

⁠

Again, there is an issue with how Jira sums up the Story Points by Assignee on this pop-up. I’ll describe more about this in the section below.

Issues with using story points in Jira

A few limitations exist in Jira when it comes to accurately reporting on story points and assigning story points correctly to issues. I’ll walk through some of these issues below and how you could solve them by using

Coda’s Jira Pack⁠

Issue #1: Story points cannot be assigned to subtasks and bugs

This is a default setting in Jira that can only be changed by your Jira admin. By default, only issues associated with epics and stories can have story points. Your Jira would have to change the

custom field context⁠

for story points in order for you to assign story points to bugs and subtasks. In the screenshot below, you’ll see a few issues in a project backlog. The first row is a bug, and the fourth row is a subtask. By default, you won’t be able to assign story points to these issues.

⁠

Screenshot on 2024-01-23 at 07-35-24.png

⁠

Issue #2: Story points from subtasks don’t add up to a total at the story level

If you have subtasks with story points assigned to them, you may have noticed that the parent of those subtasks (usually a Story) doesn’t show the sum of those story points. In the screenshot below, KPD-280 is a story with 6 subtasks. The story points field is empty:

⁠

In fact, you can set the story points for the Story to any value you want. It is completely separate from the story points of its subtasks. This is intentional on Jira’s part because in agile in you are technically not suppose to assign story points to subtasks (see Issue #1 above). Nevertheless, people still want the ability to assign story points to subtasks especially in the case where you move subtasks from one parent to another (see this

Atlassian thread⁠

Issue #3: Story points don’t add up properly for each assignee (when subtasks turned off)

If you do use story points on subtasks, you’ll also notice that the story points do not add up correctly when you click on the three dots near the top of the sprint. In the screenshot below, it appears that Eric Koleda has 50 story points assigned to him:

⁠

If you toggle the “Include subtasks in estimates” to on, however, Eric’ story points go up to 60:

⁠

Teams that use story points on subtasks (and bugs) may still want the story points to add up correctly at the parent level. We know this is true because there are Automations released by Atlassian (like

this one⁠

) that do just this. There are also various

Atlassian add-ons⁠

whose main purpose is just summing story points correctly.

How to sum up story points in Coda’s Jira Pack in a spreadsheet-like way

Access the template for this example in Coda

here⁠

After you sync your Jira issues into Coda using the

Jira Pack⁠

, you will see a

sync table⁠

of your Jira issues. This allows you to manipulate and visualize your issues as if you were using a spreadsheet. Here are the 5 issues from our sprint in Jira where you’ll see a mix of tasks and stories:

⁠

When visualized in a Coda table, these issues look like this:

⁠

A sync table of Jira issues in Coda

There are many other properties you can pull in from your Jira project into the sync table, but these are the relevant fields we need. The Story Points column pulls in whatever story points you have entered in Jira directly.

The important column to note in the sync table in Coda is the Total Story Points column. This sums up the story points for subtasks related with that story. You can write formulas in that column just like you might write a formula in a spreadsheet:

⁠

Here are all the subtasks associated with issue KPD-280 from Jira:

⁠

Most of the subtasks have their own story points. But at the parent story level, the story points value is empty. In the Coda sync table, the formula automatically sums up those values to get to the total story point value of 63. In that same sync table, I’ve unhidden all the subtasks as well:

⁠

Key Takeaway

Your team can continue adding story points in Jira and update issues in Jira, but you can do the reporting on these issues accurately in Coda. For instance, a simple bar chart can be created to visualize these 5 issues:

⁠

Popular story point estimation exercises for Jira

Still having issues getting started with coming up with story points? Here are a few exercises that can help your team get aligned on how much a story point is “worth” in the context of your product backlog:

Planning Poker - This very popular exercise requires everyone on your team to silently estimate the effort to an issue on the backlog. Then you reveal everyone’s answer and discuss why there may be differences in the estimated effort for that item. Here’s a

planning poker template⁠

T-shirt Sizing - Instead of coming up with a specific story point estimate, you assign a size to a backlog item. For each size, assign a point estimate. An S might be 2 points, an M might be 4 points, etc. Everyone assigns a t-shirt size to a backlog item and then you discuss why each person assigned a given size. Here is

a template⁠

that’s similar to t-shirt sizing but instead of sizes, you use points.

Dot Voting - Instead of a number or size, everyone on the team gets “dots” to allocate to various issues. Everyone starts placing docs on different issues on the board based on which items they think require the most effort. When everyone is “voting” at the same time, you can quickly see which items deserve the most effort. Here’s a

dot voting template⁠

Card/Bucket Sorting - Also a simple exercise where each “bucket” corresponds to a level of difficulty for completing an item. Each card in the exercise represents a backlog item and the team decides which bucket to move that card to. Here’s a

card sorting template⁠

100-Dollar Challenge - Similar to the Dot Voting exercise, this exercise gives each team member a set budget to allocate to different items. Everyone allocates their dollars based on how much effort is required to complete the item. Here’s a

100-dollar challenge template⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.