Choosing a scrum poker app
Almost every scrum poker app does the same core thing, and the differences that actually decide whether your team keeps using one are unglamorous: whether guests need an account, whether a dropped connection costs you the round, and whether the free tier fits a real team.
“App” almost always means a browser tab
Worth clearing up first, because the word sends people looking in app stores. Scrum poker is a fifteen-minute, everyone-at-once activity that ends when the meeting ends. That is the shape of thing browsers are good at, and essentially every serious tool in this category is a web app, SprintsPoker included.
The reason is not laziness, it is joining friction. Estimation only works if everybody votes, and every install between a guest and their first vote loses you someone. A URL pasted into a team channel has no such gap. If a tool asks your contractor to install something before they can pick a card, the tool has already failed at the one thing it exists for.
Native apps do earn their place where offline use or OS integration matters. Neither applies here: a round that requires all your colleagues to be online anyway gains nothing from working without a connection.
What to actually check before you adopt one
- 1
Guests join without an account
The single biggest predictor of whether a tool survives contact with your team. If a guest has to sign up, someone will not, and the session stalls at the worst moment. Test this with a private browser window before you commit.
- 2
Votes are genuinely hidden server-side
Some tools hide votes in the interface while sending every value to every client, which means the number is one devtools panel away. If the point of the exercise is to stop anchoring, the privacy has to be real and not cosmetic.
- 3
Reconnecting keeps your seat
Connections drop. If a refresh means rejoining as a new participant with the round reset, you will lose ten minutes a session to it.
- 4
Presence you can read at a glance
Who is here, who has voted, who dropped off. Without it the facilitator spends the session asking "has everyone voted?" out loud, which is slower than it sounds and grates after twenty items.
- 5
The decks your team already uses
Fibonacci at minimum, T-shirt sizes if you size a roadmap, and something for spikes. Switching scales mid-backlog invalidates your velocity history, so a tool that lacks your scale is a tool that will cost you that history.
- 6
A participant limit above your actual team
Free tiers often cap at three to five voters, which is below a real scrum team. Check the number rather than the word "free".
Run the list against a real refinement session rather than a demo. Most of these fail in ways that only show up with eight people and a flaky hotel wifi connection, which is precisely the situation where they cost you the most.
Features that sound important and are not
Voting history and analytics. Charts of estimate accuracy over time demo beautifully and get opened twice. What a team needs from history is the note explaining why an item was an 8, and that lives in the ticket, not the poker tool.
Custom deck builders. Genuinely useful about once, when you set your scale. After that a deck builder mostly enables the thing you should not do, which is changing scales mid-backlog and invalidating your velocity history.
Video and chat built in. Your team already has a call running. A second audio channel inside the poker tool is a second thing to troubleshoot at the start of every session.
Automatic averaging into a final estimate. Actively harmful. A 2 and a 13 do not average to a meaningful number, they signal that two people are describing different work. A tool that resolves the split for you removes the conversation that was the entire point of voting.
Where SprintsPoker fits, and where it does not
It fits a team that wants to start estimating in the next two minutes without a procurement conversation. Free, no account for anyone including the host, up to 50 participants, five decks, agreement scoring, spectator mode, and a room that survives a refresh. Nothing is held back for a paid tier, because there is not one.
It does not fit a team that refines directly inside Jira and wants estimates written back automatically. There is no Jira integration, and if you are sizing a hundred items a sprint, the copying will annoy you into switching. Buy the integration in that case — it is a real saving, not a nice-to-have.
It also does not fit a team that needs an audit trail of who voted what. Votes are deliberately not attributed after the reveal, and rooms expire an hour after the last activity. That is a design choice about psychological safety rather than a missing feature, but if your organisation requires the record, this is the wrong tool.
Side-by-side detail on the alternatives, including free tier caps and Jira support, is in the tool comparisons.
Common questions
Is there a free scrum poker app?
Yes, several, including this one. SprintsPoker is free with no account, no card and no trial period, and supports up to 50 participants in a room. Be careful with tools described as free that cap the free tier below a real team size or put the deck you need behind a paid plan.
Do I need to install a scrum poker app?
No, and for most teams you should not. A browser tool means guests join by clicking a link, which is the whole difference between a tool your team adopts and one they abandon. A native app only earns its install if you need offline use or deep OS integration, neither of which applies to a fifteen-minute estimation round.
Does it work on mobile?
SprintsPoker adapts to phone screens, so someone joining from a phone can vote normally. That matters less than it sounds: estimation needs the item text visible while you vote, and a phone shows you one or the other. Treat mobile as the fallback for the person who is out of the office, not the default.
What about Jira integration?
Tools that write estimates straight into Jira save a real step, and if your team refines directly from the Jira backlog that integration is worth paying for. SprintsPoker does not do it — you copy the agreed number across. For a team of five estimating fifteen items, that is a couple of minutes; for a team refining a hundred items a sprint, it is not, and you should buy the integration.
Can we use it for a distributed team across time zones?
Synchronous estimation needs everyone present, which is the real constraint rather than the tool. If your team genuinely cannot overlap, planning poker is the wrong technique and asynchronous sizing or a smaller estimating group will serve you better than any app.
Try it on three items
The only reliable evaluation is a real session. Open a scrum poker room in your next refinement, size three items, and see whether anyone complains. If the tool is right, nobody mentions it at all.