Remote planning poker with stakeholders, without the sign-up

The people who know the most about a story are often not on the team. A product owner who knows what "done" means to the customer. A contractor who built the integration you are about to change. A security specialist who will review the result anyway. Getting them into the estimation meeting is easy. Getting them to vote is where most tools make it hard: create an account, verify an email, join a workspace, find the room.

This post covers how to run remote planning poker with people outside the team, what guest voting should look like, and when an outside vote improves the estimate or distorts it.

Why outside voices matter

Planning poker works because hidden votes surface different mental models of the same work. The more of the real risk is represented in the room, the more useful that surfacing is. Outside participants bring risk the team often cannot see:

• Product owners know which acceptance criteria are firm and which are negotiable, which can halve a story.
• Contractors and other teams know the integration, the legacy module or the API quirks.
• Specialists in security, accessibility, data or compliance know the review work that will be needed whether or not anyone estimated it.

Asking these people for an opinion after the vote is not the same. By then the room has a number, and anchoring has already happened.

What a good guest experience looks like

For an outside participant, every extra step is a reason to skip the meeting. A good guest flow is:

1. One link. The host shares a link in the call chat or the calendar invite.
2. A name and a role. The guest types the name others will see and picks the role group their vote belongs to, such as Dev, QA or DevOps.
3. Straight into the room. No password, no email confirmation, no workspace to join.
4. The same vote as everyone else. Hidden until the reveal, counted in the right role average.

That is how guest voting works in EstimateTask. Each project has a share link; anyone with it joins the voting room as a named guest in a role group, votes like a member and sees the results. Guests never count against the member limit, on any plan, and their access is scoped to that one project.

Setting up the session

A little preparation makes a mixed session run as smoothly as a team-only one:

• Send the link with the agenda. Put the share link and the list of stories in the calendar invite, so guests can read the stories before the meeting.
• Tell guests which role to pick. "Pick QA" for the support lead, "pick DevOps" for the platform engineer. Their vote should land in the column whose risk they represent.
• Explain the scale once. Outside participants are often new to story points. One sentence is enough: "We compare stories to each other. A 5 is about twice as much work as a 3."
• Start with a reference story. Estimate something the whole team already knows the size of, so guests calibrate before the stories that matter.

When a guest vote helps, and when it hurts

Guest votes are most valuable when the guest owns part of the risk:

• A contractor voting on a change to the integration they wrote.
• A security reviewer voting on a story that touches authentication.
• A product owner voting on a story where scope is still open.

They are least useful, and sometimes harmful, when the guest is there to apply pressure. A senior stakeholder voting low on every story pulls averages down without adding information. Hidden votes help, because nobody sees anyone else's card before the reveal, but the cleaner fix is to invite people for their knowledge, not their authority.

Keeping votes in role groups helps here too. A stakeholder's vote in the Dev group shows up in the Dev average, where the developers can see it and discuss it, instead of silently shifting one number for the whole room.

Running the discussion

After the reveal, treat a guest's outlying vote like anyone else's: ask what they see that the room does not. Often the answer is short and decisive, like "that API rate-limits at 100 requests a minute" or "legal needs to review the wording". That one sentence is why you invited them.

If you revote, keep the guest in the room. Seeing the estimate move after their input is what makes outside participants come back next time.

Privacy and access

Guests are temporary by design. A guest joins one project from its link and can only see that project's voting room. If a link has been shared too widely, a workspace manager can regenerate or revoke it, and the old link stops working.

Retrospectives are different. In EstimateTask a retro is for workspace members only, with no share link, because retro cards carry candid feedback that does not belong behind a public URL.

Try it

You can run a mixed session today on the Free plan: one project, up to five members and unlimited guest voters, with per-role averages on every reveal. Read about estimating QA effort in planning poker, look at the features, or start free and send your next refinement invite with a guest link in it.