How to do agile estimations in Jira: faster and without planning poker meetings

Planning Poker Meetings are a time drai. A typical planning poker meeting lasts 2 to 4 hours. For a team of eight people, that’s at least 16 hours of collective time spent in a single meeting. Every sprint.

This is the standard way many teams handle their agile estimations. The goal is to reach an accurate consensus. But often, what you get is the illusion of accuracy. The final number is just a compromise to end the discussion and move on.

The asynchronous alternative to Planning Poker meetings

There’s a different way to approach this: by moving to an asynchronous culture to claim back your time.

Teams that trust each other to work autonomously don't need to sit in a room to agree on every single story point. Instead, they can estimate work through what I call interstitial collaboration, filling in the small moments between other tasks, starting and stopping the estimations according to their pace. Some folks like doing estimations during lunch break (although I recommend a real lunch break every now and then). Others prefer to start the day with that exercise, because it gets your brain up to speed.

The traits of effective asynchronous collaboration

The pace of asynchronous voting is way faster than group sessions. Removing discussions or postponing them for key areas of disagreement means that you focus on voting only. A single estimation conducted individually shouldn’t take more than 30 seconds to a minute. I haven’t found data on this, but voting in bulk should speed that up even more. I bet you can get an entire backlog estimated in 20 minutes!

On the other hand, it’s important to acknowledge that asynchronous collaboration isn’t always efficient. A recent study by getquotient shows that efficient async teams have common traits that include the following:

• Burstiness. Rather than spreading collaboration throughout the day or the week, there are “bursts” of activity. For example: when a team lead asks the team to vote on every work item in a shared list

• Responsiveness. In essence: when such a request is shared, teams that respond quickly to it are more effective that those that don’t

My advice: don’t just remove a planning poker meeting: replace it with a responsive, structure collaboration pattern!

A visual demonstration of “bursty” communication patterns, where darker lines show higher communication frequency. C shows the most accurate example of a “bursty” team, including some longer wait times followed by bursts of activity, especially in the beginning, middle, and toward the end of the challenge. Source: Getquotient

But before we dive into how to run async agile estimations in Jira, let’s do a quick review of the existing alternatives for estimating story points in Jira.

How to handle agile estimations and story points in Jira

There are a few options for running a Jira story point estimation session. Let's look at them..

1: The manual way to estimate issues and work items in Jira (Native Jira Fields)

The simplest way is to just use Jira's built-in story points field manually.

If you’re happy with this process, you probably fall in these two categories:

• Individual ownership. Somebody is estimating alone, without discussing with anybody else. The result? You guessed it: biased estimates that only belong in the owner’s mind.

• Group ownership. There is some discussion, which means that you’re still doing a meeting. And probably not the most structured you’ve ever been to. You might be doing a fairly good amount of manual work copying the keys of the work items to a spreadsheet or Confluence table, or simply going with the flow without documenting any of the discussion process.

Assuming that story points are valuable for your team, you should be a bit more ambitious. Let’s see what’s the next option:

2: Estimating story points in Jira with a Planning Poker app

The next step for many teams is a dedicated planning poker Jira integration. These apps formalize the estimation meeting inside Jira.

The UI of Appfire’s Planning Poker, the leading app for estimations in Jira

What’s good about Planning Poker Apps for Jira?

• They’re transparent. Everyone votes at the same time, and the results are shown on screen.

• They build great conversations. Especially when votes are far apart. And those conversations can show how far apart are the assumptions of different team members about the job.

• They remove bias. By voting independently, everyone can make their own mind instead of agreeing to what the Scrum master said.

What’s not so good about Planning Poker Apps for Jira?

• They’re huge time wasters. As we saw above, an estimation meeting can kill at least half a day of work per sprint. Add that to other agile rituals, and the result looks ugly.

• They can become a pointless ritual. In the end, it’s not that important whether a task is a 5 or an 8. But in large groups, discussions often take their own life… and never end.

• They can be expensive. Particularly because of how Atlassian charges for apps, if some of your teams are using these apps, you’ll have to pay for every Jira user. Let’s see an example: an instance with 410 users will have to pay over 7k yearly, even if only three teams are using it.

Alternative 3: Asynchronous collaboration with Shared Estimations

There’s a third option: an async Jira estimation tool like Shared Estimations (formerly known as Open Poker). This is a more minimalistic approach.

Here’s how it works: A list of issues is shared with the team. Each person enters their estimate on their own time. The app simply shows the average estimate. If the numbers are close, the average is used and everyone moves on. If they're far apart, it flags the issue for a quick chat. That’s it.

What’s good about async estimation apps for Jira?

• Faster: It eliminates the need for a dedicated planning poker meeting. It respects everyone's focus time and works well for distributed teams. It trusts developers to do their work.

• Focus: The app doesn’t add more interruptions to the team, allowing everybody to work towards their goal.

• More affordable: Because they don’t need to work on a great interactive meeting experience, these solutions often solve the problem of gathering data without having to invest in expensive and bloated features. In the end, the monthly can be as little as 20% of what you’re already paying.

• Still prevents bias and promotes transparency: Since all votes are still gathered independently and only shown when the voting has finished, voters can’t be biased by group thinking. In fact, asynchronous estimations are way less biased, since meetings can introduced all sorts of psychological cues and anchors that already exclude possible estimation values.

What’s not so good about async estimation apps for Jira?

• What’s not so good: async estimation won’t work for every team. It requires a culture of asynchronous collaboration where people are responsible and autonomous. If your team isn’t there yet, this might not be a good fit… but it’s worth trying!

Comparison: Asynchronous vs. Synchronous estimation methods

Agile estimation methods that work asynchronously

Whether you're in a meeting or using an async tool, the methods for estimating are the same. These are popular choices for agile teams.

• Fibonacci Sequence: A sequence where each number is the sum of the two preceding ones (1, 2, 3, 5, 8, 13...). The growing gaps between numbers represent increasing uncertainty. This is a common method for story points.

• Linear Sequence: A simple 1-10 scale. It's straightforward and easy to understand for teams new to story point estimation.

• T-Shirt Sizes: Using sizes like XS, S, M, L, XL. This is great for getting quick, high-level estimates without getting stuck on specific numbers.

• Fist to Five: More of a confidence vote. Each person holds up a number of fingers (from 0 to 5) to show how confident they are in an estimate or a plan. It can be adapted for async feedback.

• Wisdom of the Crowd: The Wisdom of the Crowd principle suggests that the average estimate from a group of individuals is often more accurate than any single person's guess. In this method, instead of removing bias the owner offers 4 alternative estimates, and the users vote on them. The result is the average of all votes.

Conclusion

The verdict is in: agile estimation doesn't have to be a four-hour meeting. The core purpose of estimating is to gain a shared understanding of effort, not to debate every last story point to death.

By moving this process out of a meeting and into an asynchronous workflow, you eliminate the single biggest pain point: wasted time. You keep the benefits of unbiased, independent voting while giving your team the freedom to focus on what they do best: building great software.

Stop letting planning poker dictate your calendar. Take the next step and try Shared Estimations for your next sprint. It’s the faster way to reach consensus for agile teams. You'll get faster estimates, a more focused team, and a much lighter meeting schedule.