Why we built Sync Poker: security-first Planning Poker for Jira that Runs on Atlassian
There are already many Planning Poker apps for Jira.
So why did we build one more?
For us, the answer started not from features, but from security.
Planning Poker looks simple from outside: people select cards, votes are hidden, then the team reveals estimates and agrees on the final value.
But in Jira, estimation is connected to real work items. These work items can contain product plans, technical details, customer context, priorities, and internal discussions.
For many companies this is sensitive information.
So the question is not only:
“Does this app support Planning Poker?”
The question is also:
“Where does our Jira data go?”
“Who operates the infrastructure?”
“Can admins control external data sharing?”
“Can this app pass our security review?”
“Can we approve it without adding unnecessary risk?”
This is why we built Sync Poker.
At Do Async, security is very important for us. Our company is SOC 2 compliant, and with Sync Poker for Jira we wanted to go further: build a modern real-time Planning Poker app for Jira that Runs on Atlassian.
Built with trust as a requirement
From the beginning, Sync Poker was designed with security, trust, and Atlassian-native architecture in mind.
This was not only a technical decision. It was a product decision.
When a Jira app works with work item data, estimation fields, participants, votes, and session activity, customers should understand how this app fits into their security model.
That is why we wanted Sync Poker to stay as close as possible to the Atlassian ecosystem.
We built Sync Poker on Atlassian Forge and designed it around the trust expectations of Jira Cloud customers.
Security should not be something that is added later, after the product is already finished. It should influence architecture, permissions, data handling, and even which features we decide not to build.
Caption: Sync Poker stores and processes app data within Atlassian apps and services, with clearly declared analytics and logging settings.
Admins stay in control
We also wanted to be transparent about analytics and logs.
Sync Poker declares optional external data egress for analytics, logs, and custom metrics through PostHog and Sentry. This excludes in-scope End-User Data.
We use these tools because they help us understand how the app is used, detect errors, and fix problems before customers need to report them.
But we also understand that some companies have stricter security rules.
That is why Atlassian admins can disable analytics, logs, and custom metrics if they want more control over external data sharing.
Caption: Atlassian admins can disable analytics, logs, and custom metrics access from the admin settings.
If these settings are disabled, Sync Poker still works. The trade-off is that we have less visibility into product usage and errors, so it is harder for us to improve the app and fix issues early.
For us, this is the right balance: customers stay in control, and we are open about the limited external tools that help us maintain the product.
Why not just add it to Async Poker?
We already build Async Poker, so it is fair to ask:
Why did we not just add real-time Planning Poker there?
The reason is not only user experience. It is also architecture and security model.
Async estimation happens over time. People may vote today, tomorrow, or later in the week. Because of that, an async process needs external communication channels: Slack notifications, email notifications, and Microsoft Teams notifications coming soon.
These notifications are important for Async Poker. Without them, async estimation becomes much harder to manage, because people need reminders and updates outside the estimation screen.
But these integrations also mean a different architecture. The app needs to communicate with services outside Atlassian. This is normal for async workflows, but it is not the same security model as an app that tries to keep the live estimation flow inside Atlassian as much as possible.
With Sync Poker, we wanted to protect a different goal.
Live Planning Poker happens when the team is already together. The team opens Jira, starts the game, estimates work items, discusses differences, and saves the final estimate back to Jira.
Because the workflow is live, we do not need to build the product around Slack, email, or Teams notifications.
This gave us a chance to build Sync Poker with the Runs on Atlassian goal in mind from the beginning.
If we added Sync Poker into Async Poker, we would mix two different products, two different workflows, and two different trust models. The result could be a heavier product and a less clear security story.
That is why we decided to build Sync Poker as a separate app.
Caption: Create a Sync Poker game with a moderator, participants, timers, visibility settings, and estimation cards.
Security and usability should work together
A secure app still needs to be easy to use.
If the estimation flow is too complicated, teams will not use it. If it feels disconnected from Jira, people lose context. If it takes too long to prepare a session, the meeting already starts with friction.
That is why Sync Poker is designed to feel native to Jira.
Teams can select Jira work items, choose the estimation field, run a live estimation session, and save the final value back to Jira.
The goal is simple: keep estimation close to the place where the work already lives.
Caption: Select Jira work items, filter by fields, and prepare the estimation session without leaving Jira.
The team stays in control
Planning Poker is not only about the final number.
The real value is the discussion.
One developer may see backend complexity.
A QA engineer may notice testing effort.
A product manager may clarify the expected scope.
Another teammate may remember a similar work item from the past.
Good estimation is not just voting. It is alignment.
Sync Poker supports this live flow with private estimates, reveal, revote, consensus information, vote distribution, reference work items, and saving the final estimate back to Jira.
The app helps structure the conversation, but the team stays in control.
Caption: Review consensus, vote distribution, and a recommended estimate before saving the final value back to Jira.
Why this matters now
The Atlassian Marketplace has changed.
Customers are more careful when they choose apps. Security teams are more involved. Procurement reviews are more detailed. Data residency, app hosting, logs, analytics, and data egress are now normal questions.
This is a good change.
It pushes vendors to build better apps.
For us, Sync Poker is our answer to this change.
We believe teams should not choose between a good Planning Poker experience and a stronger security posture. They should be able to use a modern real-time estimation app from a SOC 2 compliant vendor, built to feel native to Jira and aligned with Atlassian Cloud security expectations.
That is why we built Sync Poker.
Not because Planning Poker did not exist.
But because we believed there was room for a Planning Poker app with a different priority: security first, Atlassian-native, and focused on teams that want their estimation process to stay close to Jira.
Sync Poker is still evolving, but the direction is clear:
real-time Planning Poker for Jira, built for modern teams, with trust as a core part of the product.
Was this helpful?
Thanks!
Anton - Do Async
0 comments