📖 What are story points in Jira and how to estimate them? Jira Guru

[#1]

Hi community, 

This is Wednesday again, and Weekly knowledge growth with Jira Guru!

Today's topic is "Story Points in Jira"

----

What are Story Points in Jira?

When we talk about story points, we're not discussing time like hours or minutes. Instead, we're discussing effort. Let's say you have two tasks: a quick email and a detailed report. If you had to compare them, you'd intuitively know the report demands more attention than the email. Story points capture this essence, reflecting effort without getting hung up on the exact time.

Story points shine in agile planning, especially with scrum teams. They offer a way to gauge tasks and monitor progress more transparently. It's like labeling each task with its level of effort or complexity.

In the realm of Jira, these tasks referred to as "stories" or "epics" can be assigned these points, indicating their 'weight' in terms of effort. Usually, primary tasks like stories or epics get these points, leaving out smaller sub-tasks like bugs. However, Jira is adaptable, so if teams feel the need to adjust this, they can, with the right permissions.

How to Add Story Points in Jira?

Utilizing story points in Jira can transform your team's workflow, bringing clarity and direction. By estimating effort with these points, you're setting the stage for improved progress tracking and resource allocation.

For those with Team-Managed Projects:

1. Navigate to Project Settings > Features. There, you'll find the Estimation (Story Points) option. Turn it on.
2. In any Jira issue, look for the Story Points estimation on the right.
3. Click the field, add your estimate, and then click outside to save.

For those using Company-Managed Projects:

1. Open a Jira issue. If the Story Points field isn't visible, click on Configuration at the bottom right.
2. On the Issue layout screen, peek into the Hidden Fields section. If the Story Points field is there, drag and drop it to your desired view.
3. If it's absent, follow the guide for the custom field in Jira. From there, pick the Story Points field.
4. With the field enabled, open any Jira issue. You'll see the Story Points field to its right.
5. Click the field, input your estimate (often in hours), and click outside the box to save.

How to Use Story Points in Atlassian’s Jira?

We've chatted about what story points are and how to add them in Jira. But how do you actually use them to make your project management smoother and more effective?

First things first, story points are all about understanding effort. Not the exact minutes or hours a task will take, but a relative sense of how big or challenging a task is compared to others.

1. Start with a Baseline Task

When you're just starting with story points, pick a common task as your baseline. Say, designing a webpage or writing a piece of code. Assign it a value—maybe it's a '3'. Then, as you encounter new tasks, compare their complexity to this baseline. Is it twice as complicated? Then maybe it's a '6'. Half as tough? Then it's probably a '1.5' or '2'.

2. Host Estimation Meetings

Gather your team for a dedicated session. As you discuss upcoming tasks, estimate the story points together. It’s a collaborative effort, and everyone's perspective helps in reaching a consensus. Remember, it's not about being precise down to the last minute. It's about getting a feel for the task's size and complexity.

3. Track and Adjust

After you've completed a few tasks, look back. Did a 5-point task take much longer than expected? Or was a 2-point task surprisingly time-consuming? Adjust your future estimates based on these experiences. Story points are dynamic, and it's okay to recalibrate as you learn more about your team's pace and the nature of tasks.

4. Use Jira’s Reporting Tools

Jira offers robust reporting tools that can help teams understand their velocity – that's the number of story points they can complete in a sprint. By tracking your team's velocity over time, you can predict future performance and adjust plans accordingly.

You can select a Report Tool or view straight backlog insight. 

5. Remember, It's About the Big Picture

Story points aren’t about micromanaging every minute. They’re about understanding the broader landscape of work. Use them to guide sprint planning, assess team capacity, and ensure no one's overloaded.

Other Popular Estimation Techniques for Jira

Estimation is an art as much as it's a science. Over the years, agile teams have developed various techniques to estimate tasks, helping them determine the amount of work or complexity involved in completing them. Here’s a closer look at some of the most popular methods:

1. Planning Poker

• What It Is: This game-like method involves team members making secret estimates using cards, then revealing them simultaneously.
• How It Works in Jira: Each task is discussed one by one. Team members select a card (or a virtual card if using a Jira add-on) that represents their estimate in story points. After everyone reveals their cards, the team discusses the rationale behind their choices, especially if there are significant differences, and then converges on a consensus.
• Benefits: Encourages team discussion and reduces the influence of dominant team members on estimations.
• Jira Application: Use Jira add-ons or integrations like "Planning Poker" or simply use comments and custom fields to record estimates.

2. T-Shirt Sizes

• What It Is: Tasks are estimated based on 'sizes' like XS, S, M, L, XL, mirroring t-shirt sizes.
• How It Works in Jira: In Jira, teams can map t-shirt sizes to numeric story points. For instance, XS could be 1 point, S could be 3 points, and so on. This abstracts the estimation process, making it more about relative sizing than exact numbers.
• Benefits: Simplifies the estimation process and is especially useful for initial rough estimates.
• Jira Application: Use custom fields to record T-Shirt sizes. Convert these sizes to numerical story points if needed.

3. Dot Voting

• What It Is: Team members are given a set number of dots (or votes) to place on tasks based on their perceived effort or complexity.
• How It Works in Jira: Tasks can be displayed on a digital board, and team members allocate their dots to the tasks they feel are most demanding. Tasks with more dots are deemed more complex. This can be combined with story points for finer granularity.
• Benefits: Engages the entire team and quickly highlights tasks that might need more attention or resources.
• Jira Application: Implement using Jira labels or custom fields. Various Jira plugins are also available to facilitate dot voting.

4. Affinity Estimation

• What It Is: A method where tasks are grouped by similarity in size or complexity.
• How It Works in Jira: Tasks are laid out, and the team collaboratively groups them based on perceived effort, without assigning exact numbers initially. Once tasks are grouped, each group is given a story point value.
• Benefits: It's a collaborative approach that helps in quickly sorting large numbers of tasks and encourages team discussions about task complexities.
• Jira Application: Use Jira boards to visualize tasks, grouping them in columns or swimlanes based on complexity.

5. Bucket System 

• What Is It? The Bucket System sorts tasks into "buckets" based on their relative complexity. Each bucket corresponds to a range of story points.
• How It Works:

Buckets Creation: Create buckets, often using Fibonacci-like sequences (e.g., 0, 1, 2, 3, 5, 8, 13).

Task Sorting: Team members discuss and place each task under a bucket label that reflects its size.

Point Assignment: Tasks are given story points based on their bucket.

• Benefits: It's a quick method, especially useful for larger backlogs. Promotes team collaboration and reduces individual bias.

• Jira Application: Utilize custom fields for bucket labels. Tasks can be dragged into different bucket categories on Jira boards.

Common mistakes made when using Story Points

Equating Story Points to Hours Spent or Value:

• Mistake: Teams often make the error of directly translating a story point to a specific number of hours or days. Some also make the mistake of equating story points directly to the business value.
• Why It's a Problem: Story points are a measure of complexity, effort, and uncertainty, not an exact metric of time or value. By binding them to a time value, teams risk compromising the flexibility and purpose of story points.

Adjusting Story Point Estimates of Issues During the Sprint:

• Mistake: Sometimes, in the middle of a sprint, a team might feel that a task is harder than initially thought and adjust its story points.
• Why It's a Problem: Changing story point estimates during a sprint can distort the sprint's velocity and make it difficult to plan future sprints. It's better to reflect and adjust in future sprints.

Never Story Pointing Bugs:

• Mistake: Teams might choose not to assign story points to bugs, believing they're "unplanned work" or that they're too unpredictable to estimate.
• Why It's a Problem: If a team spends a significant amount of time addressing bugs, not pointing them out can give an inaccurate representation of the team's capacity and velocity.

Adding Story Points to Small Tasks:

• Mistake: Teams sometimes assign story points to very minor tasks, making them seem more significant than they are.
• Why It's a Problem: Assigning story points to minuscule tasks can inflate a team's velocity without a corresponding increase in delivered value. It's better to group small tasks or set a minimum threshold for what gets pointed.

Story Pointing Unfinished Issues Again:

• Mistake: If an issue isn't completed in one sprint, teams might re-estimate and assign new story points when it rolls into the next sprint.
• Why It's a Problem: This can lead to double-counting and can inflate velocity. The initial story points should remain, and the team should reflect on why the task wasn't completed.

Stay tuned for more Jira Information and remember, being a 'JIRA GURU' is all about continuous learning!

------------

Learn more about Jira, Confluence and Atlassian with Jira Guru

👉 Visit Atlassian Marketplace

💬  If you have any questions or suggestions for the next topic please leave a comment below 👇

🙌  Please like, and share this article with new beginners

[Frankie C.]

Conversations around story points pop up all the time, especially as new orgs/teams lean more into agile delivery... this is a great summary around what they are, what they aren't, and different ways to drive the right mindset around estimation. Cheers!

[Randy O'Neal]

I can almost hear the sacred cows moo-ing in the background, lol.  Lots of sacred cows surround the concept of story point estimation.  Perhaps the most significant is that Ron Jeffries - the person who created the concept of story points - now wishes he'd never even conceived of them.  Here's a quote from Ron himself:

Ron Jefferies, the creator of story points, has eventually agreed himself that creating story points was a mistake. He said: “I like to say that I may have invented story points, and if I did, I'm sorry now.”

I've preached about every aspect of story point estimation in my career.  I adhere to the concept that - despite everything we claim that story point estimation represents complexity - I firmly believe story points ultimately boil down to duration; not specific duration (as in "a 3 point story takes 3 days"), but more general duration (as in "a 3 point story likely takes 2 to 3 days").  I'm happy to be branded a story point heretic; I believe I am in good company.

We are currently running an experiment with our Kanban teams.  Considering Kanban teams operate best with right-sized stories, and that most Kanban teams operate best when stories can be completed within 3-5 days max, we have abandoned story point estimation altogether.  Rather than asking our team for a story point estimate, we now ask our teams whether a story (or issue) can be completed within 3-5 days; if the team believes it can, we consider it Ready; if not, we split the story and ask again.  We're about 6 weeks into this experiment, and our throughput and cycle time seem to be stabilizing, and the team is operating well under this new paradigm.  We've also abandoned sub-task hour estimation in the same spirit, and thus far, it has served us well.  We feel we're embracing the spirit of the Agile concept of YAGNI (You Ain't Gonna Need It) in doing so; we do not use sub-task hour estimates for time tracking purposes, and I realize that wouldn't fly for a lot of companies... but it does for ours.

Like I said... lots and lots of sacred cows surround this topic, and I suspect I've trampled on several - not my intent.  Just food for thought...