Async estimation: planning poker without the meeting

Async estimation is planning poker spread over time. Instead of meeting, each person reads the items and votes privately whenever it suits them before a due date. The votes stay hidden until voting closes; then the team looks at the results together and only discusses the items where people disagree. It replaces the meeting for straightforward items. It doesn’t replace the conversation.

It works best for distributed teams, busy calendars and long lists of well-understood items, and worst for vague or risky work that needs a whiteboard. Used well, it frees your live time for the handful of items that deserve it. Used badly, it turns estimation into a form people fill in without reading.

What is async estimation?

Async (short for asynchronous) estimation keeps the core of planning poker: independent votes, hidden until everyone has voted, followed by a discussion of the differences. What it drops is the need to be on the same call at the same time. People vote over a day or two, usually with a short comment explaining their reasoning, and the team reviews the results once voting closes.

The idea is older than planning poker. In the Wideband Delphi method, which Barry Boehm and John A. Farquhar developed in the 1970s, experts filled in estimate forms anonymously, a coordinator circulated a summary, and the group met to discuss the points where the estimates varied most before estimating again. Async planning poker follows the same rhythm, with an online tool in place of the coordinator’s paperwork.

When async estimation fits, and when it doesn’t

Async is a good fit when:

• The team spans time zones. If the shared window is two hours a day, spending one of them reading tickets aloud is a waste.
• The items are well understood. Small changes to familiar parts of the product, follow-ups to work just finished, items whose acceptance criteria say it all.
• The list is long. Twenty small items after a planning workshop would fill a whole meeting; async lets people work through them at their own pace.
• People need thinking time. Some people estimate better after looking at the code or the designs properly, which a live round rarely allows.

Keep the item for a live session when:

• Nobody quite knows what it means yet. If you expect a dozen questions, a conversation will settle them faster than a comment thread.
• The approach is undecided. “Replace the nightly batch import with event streaming” needs a design discussion before anyone can size it.
• The team is new. Until a team has shared reference stories and some history, live rounds build the common understanding that async relies on.
• It’s big or contentious. Items likely to land on 13 or more usually need splitting, and splitting is a group activity.

Good async candidates look like “Return a 404 instead of a 500 for unknown order IDs”, “Add a copy-link button to shared reports” or “Rename Customer ID to Account number across the admin screens”. A poor one looks like “Support multiple currencies in invoicing”.

How to set up an async round

1. Choose 5 to 15 items. Pick items from the top of the backlog that you expect to plan in the next sprint or two. Beyond 15, people start skimming.
2. Make every item stand on its own. Give each one a description, acceptance criteria, links to designs and any known constraints. Nobody can ask a quick question across the table, so the item has to answer it in advance.
3. Confirm the deck and the yardsticks. Use the team’s usual deck and link two or three reference stories in the invitation, so everyone compares against the same things.
4. Set a due date. Say when voting closes, and when and how the team will review the results.
5. Explain the rules once. Vote privately, add a one-line reason, use “?” when you genuinely can’t judge, and don’t share your number in the team chat.
6. Nudge once, then close. A single reminder halfway through is enough. When the due date arrives, the moderator closes voting and everything is revealed at once.

On planningpoker.org Async Poker, available with a free Laya account, lets everyone vote on their own time before a due date, with optional comments. A moderator finishes voting and the team reviews the results together.

Choosing a due date

A due date is what turns “vote when you can” into a round that actually finishes. Allow one to two working days: long enough to fit around other work, short enough that nobody forgets the round exists. Then a few practical rules:

• Work back from sprint planning. Close voting at least a working day before planning, so there is time to review the split items and refine anything that needs it.
• Set the deadline in the last time zone. “Wednesday 17:00” means different things in Toronto and Kraków. Pick a time at the end of the working day for the furthest-west member and write the time zone with it: “Wednesday, 17:00 Toronto time” is late evening in Kraków, after everyone there has had their day to vote.
• Avoid Friday deadlines. A round that closes on Friday afternoon gets rushed votes, then a Monday review by people who have forgotten the details.
• Keep it fixed. If the due date moves every time someone is late, people learn that it doesn’t matter. Close on time and deal with missing votes in the review.

Comments: the async version of the discussion

In a live round, the reasoning comes out after the reveal. In an async round it has to be written down, which is why a one-line reason with each vote matters so much. Without reasons, the review has nothing to work with except the numbers.

Good comments state the assumption, the risk or the question behind the vote. Here is what a round on “Let customers pause a subscription for up to three months” might produce:

• 3: “If pausing reuses the cancel flow and just sets a resume date, this is mostly UI.”
• 8: “Billing has to prorate a pause that starts mid-cycle, and the invoice service doesn’t support that yet.”
• ?: “Can customers on annual plans pause? The acceptance criteria don’t say.”

Those three comments do the work of a ten-minute discussion. The product owner can answer the annual-plan question before the review, and the team can decide whether proration belongs in this story or in its own. Encourage people to write the reasoning rather than the size (“UI only if we reuse the cancel flow”, not “easy 3”), so a comment never becomes an anchor for anyone still voting.

The review: where the value is

Closing the vote is only half the job. The review is where async estimation earns its keep, and skipping it is the quickest way to lose what makes planning poker worth doing. Sort the revealed items into three groups:

• Agreed. Everyone voted the same, or nearly. Accept the estimate, glance at the comments for surprises and move on.
• Close. Votes on two neighbouring cards, such as 3 and 5. Read the comments and settle it in a minute; often one comment shows what the lower voters missed.
• Split. Votes more than one card apart, such as 3 and 13, or several “?” cards. These need a conversation: the outliers explain, the team votes again, and if it still won’t converge, the item goes back to the product owner or gets split.

The review can be a short call or a written thread. Keep a call to 15 minutes and cover only the close and split items; a short voice conversation settles a disagreement faster than a long comment thread. If time zones make even that impossible, run the discussion in writing with a named owner and a deadline for the decision.

Suppose a team votes async on 12 items and finds 7 agreed, 3 close and 2 split. The review covers 5 items in a quarter of an hour, and the conversation happens exactly where it’s needed. Record each decision, and any assumption it rests on, on the item itself.

Common pitfalls, and how to avoid them

• Losing the discussion. Taking the average without talking hides the one person who spotted the problem. If three people vote 3 and one votes 13, the 13 may be the most valuable vote in the round. Never let a split item through without a conversation.
• Drive-by voting. Votes cast in ten seconds without opening the designs are noise. Asking for a reason with every vote slows people down just enough.
• Anchoring through the side door. “Just voted, I went 2” in the team chat undoes the hidden vote. Keep numbers out of chat until the reveal.
• Sending the hard items async. It’s tempting to push the items nobody wants to discuss into an async round, but they are exactly the ones that need discussing.
• Stale votes. If the product owner rewrites an item halfway through the round, earlier votes were cast on a different item. Ask people to vote again.
• Never closing the loop. If people never hear what was decided, they stop putting effort into their comments. Share the final estimates and the reasons after the review.

Mixing async and live estimation

Async doesn’t have to replace live sessions. Use each where it’s strongest:

• Async first, live for the splits. Everyone votes async on the upcoming items, and the live slot covers only the items that split. This is the simplest pattern for distributed teams.
• Live for the new, async for the routine. Big or unfamiliar items get a live round in refinement; small follow-ups and well-trodden changes go async.
• Async as a pre-read. A quick async vote before a backlog refinement session shows the facilitator where the disagreements are, so the meeting starts with the items that need it.

A two-week rhythm for a team spread across Europe and North America might look like this: the product owner posts ten items on Monday, voting closes on Wednesday at 17:00 Toronto time, the team holds a 15-minute review on Thursday during the shared window, and everything is ready for sprint planning the following week. For the live part of that rhythm, our guide to remote planning poker covers the call itself.