Trust and security: Planning Poker Agility

Planning Poker Agility is a free planning poker app for Jira Cloud. This page describes its new version, built on Atlassian Forge, which a site gets when its admin updates the app (Moving to Atlassian Forge). Its tables, cards and AI features run on our own servers: your data is stored in London (UK) and processed in Stockholm (Sweden), on Amazon Web Services. Its AI features use OpenAI, which processes the text it is sent in the United States.

Each Agile Pulse app is built differently, so each has its own trust page; this one covers Planning Poker Agility. Compare all seven apps.

At a glance

Architecture and data flow

How Planning Poker Agility is connected, at a high level: where it runs, where your data goes and who keeps it. Each number matches an entry in the list under the diagram.

In words

1. People use Planning Poker Agility inside Jira, signed in with their Atlassian account.
2. Planning Poker Agility reads from Jira as it works. In Jira: the estimates people save, and what Ready or Not adds when someone asks it to: text added to a description or acceptance criteria field, comments, new split issues and the ai-made-ready label.
3. The app’s Forge functions call our servers to run tables (cards played, estimates and notes) and to make AI requests. Sent over HTTPS (TLS).
4. Only when someone sends a message from the in-app Contact us form: the person types a subject and a message, and the app adds the Jira site, the app version and their email address from their Atlassian profile, so we can reply; it asks for an address only when Jira does not share one. The message goes through the app to our servers, which email it to our support team through Amazon Web Services’ email service in Stockholm (Sweden). Our servers do not keep the message. Sent over HTTPS (TLS).
5. The browser keeps a secure WebSocket open to our servers for live updates at a table. Sent over Secure WebSocket (TLS).
6. Our application servers keep your data in the database with MongoDB Atlas, on Amazon Web Services, in London (UK), and reach it over TLS. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
7. Optional: only when someone uses an AI feature and AI is on for the site: our servers send OpenAI only the fields listed under How AI is used. Never sent to OpenAI: any person’s name or account details from Jira, Jira comments, attachments, cards played, email addresses, or who is at a table. OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer. We never store the prompt. Sent over HTTPS (TLS).

The Planning Poker Agility Architecture Diagram and Data Flow has the diagram with a table of what is kept where and how it is protected, and prints as a document for your records.

What we store

Our servers keep the Atlassian account id of each person at a table, with the display name and avatar address Jira showed, the cards they play and the notes they write. They also keep each person’s answers to the confidence check. For people who start a player card, they keep the card under the person’s account id, and the person’s place in their team’s table. For people who deleted their card, they keep only their account id and the date, so no new card starts by itself. A player card, a team’s table and that note hold no name.

In your Atlassian site

• Forge storage on your site: one record of when the daily personal data report last ran (dates only, no account ids). The rest of the app’s Forge storage serves an optional Laya.net connection, which this version does not offer.
• Jira itself: the estimates people save, and what Ready or Not adds when someone asks it to: text added to a description or acceptance criteria field, comments, new split issues and the ai-made-ready label.

On our servers

• Tables: the name and settings, the ids and keys of the Jira issues picked, the cards played and final estimates, notes written at the table, timers and AI hints.
• People at a table, and people asking to join a private one: their Atlassian account id, and the display name and avatar address Jira showed.
• Quick estimates in an issue’s Planning Poker Agility panel: the issue’s id and key, the account id and card of each person who played, and the final estimate.
• Player cards, one for each person on the site who started one and hasn’t deleted it (a card starts the first time the person is at the table, or when they save their figure while achievements and stats are off; after they delete it, only when they press Start my player card): their account id, when their card started, their achievements and the date of each, stat counts, card mix (how often they played each card value), the look of their figure, the items they unlocked, whether they hide their achievements and stats, and up to 2,000 one-way keys that stop double counting and name no one. A card holds no name. People at a table with them see their figure, and their achievements and stats unless they hide them; the card mix and the count of thanks they received are shown only to them.
• Deleted player cards, one note for each person on the site who deleted their player card and hasn’t started a new one: their account id and the date, nothing else, so that no new card starts by itself. Nobody sees it. It is removed when they press Start my player card, or when their Atlassian account is closed.
• Team tables, one for each Jira project whose tables someone with a player card sat at: the team’s counts, such as rounds played and issues settled, its runs of first-round agreements, its achievements and the date of each, its unlocks, up to 2,000 one-way keys that stop double counting and name no one, and the account ids of the people with a player card who sat at its tables. Team stats are shown only to those people, only when there are 3 or more of them, and never per person.
• Confidence check answers, kept with the table: for each issue, each person’s answer (confident or unsure), their account id and when they answered. People at the table see each answer on the person’s figure.
• Ready or Not results: each scanned issue’s key, summary and type, the AI’s assessment and suggestions, and the account id of the person who ran the scan.
• Project settings: reference issues (yardsticks), Definition of Ready rules, the estimation field and deck, and which issue fields the issue details show.
• Site settings: the Enable AI setting and the achievements and stats switch.

What we never store

• Issue descriptions, Jira comments and attachments: the app reads them live from Jira.
• The prompts sent to OpenAI: each is built for one request and deleted straight after.
• A copy of your Jira projects: our servers keep only the issue ids and keys a table uses and, for Ready or Not, each scanned issue’s summary.
• Reactions, and who is at the table right now: our servers pass reactions on to the people at the table as they happen, and hold who is at the table only in memory while it is open.
• Table style choices, and the view each person opens tables in: they stay in each person’s browser.

How AI is used

AI runs on our servers, not on Atlassian. Our servers, on Amazon Web Services in Stockholm (Sweden), send each AI request to OpenAI’s API, using our own OpenAI account.

Never sent to OpenAI: any person’s name or account details from Jira, Jira comments, attachments, cards played, email addresses, or who is at a table. Text people typed into the fields that are sent, such as a name written in a description, is sent as typed.

Model training

OpenAI’s API terms say it does not use data sent to its API to train or improve its models unless the customer opts in to share it. We do not train or fine-tune any AI model on your data.

What the AI provider keeps

Under OpenAI’s standard API terms, OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer, and then deletes it; the services our requests use keep nothing else. On our side, each prompt is built for one request and deleted straight after: we never store it. We keep only the AI’s answer: AI hints with their table, and Ready or Not results, in our database with no expiry (see "Retention and deletion").

Turning AI off

A Jira admin can turn AI off for the whole site: on the app’s Get started page (in Jira settings, under Apps), switch off Enable AI under AI Settings. While it is off, our servers refuse every new AI request from that site.

Whoever sets up a table chooses whether it has AI hints, and only a table’s host can ask for one (our servers check that). Ready or Not and the AI search helper run only when someone uses them; nothing runs on a schedule.

Where data is held

Your data is held in Europe (Sweden and the UK): stored in London (UK) and processed in Stockholm (Sweden). When someone uses an AI feature, the text sent is processed by OpenAI in the United States. Atlassian’s data residency settings do not cover data on our servers.

Connections outside Atlassian

Sub-processors

We update this list at least 30 days before a new sub-processor starts processing your data.

Retention and deletion

• Uninstall: Nothing on our servers is deleted when the app is uninstalled: the app has no uninstall step.
• Deletion: Deleting a table in the app marks it deleted, and the record stays in our database. Nothing expires automatically. A person can delete their own player card with Delete my player card: their card, their place in team tables and their confidence check answers on that site are deleted, and nothing more is counted for them. A note that they chose to have no card (their account id and the date) is kept, so no new card starts by itself until they start one. The cards they played, their notes and the team counts stay.
• Atlassian’s personal data reporting: The app uses Atlassian’s personal data reporting every day. When Atlassian reports a closed account, we replace its id with a random one and remove its name and avatar; its cards and notes stay, anonymised. Its player card and any note that it chose to have none are deleted, and its confidence check answers and its place in team tables are removed.
• Logs: Our servers keep access logs, which hold IP addresses, for no more than 30 days.
• Deletion requests: to ask for your site’s data to be deleted, email privacy@laya.net.

Security practices

• Only encrypted connections: the app reaches our servers only over https and wss.
• Ready or Not’s changes to Jira are made as the person who asked for them, so Jira’s own permissions apply.
• Site settings save only for Jira admins.
• Encryption: All connections are encrypted: browsers and the app’s Forge functions reach our servers only over https and wss, and our servers reach the database over TLS, which MongoDB Atlas requires for every connection. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
• Atlassian Marketplace programmes: In Atlassian’s Cloud Fortified and Marketplace Bug Bounty programmes.

Common security questions

Contact

• Security: support@laya.net, with "Security report" in the subject line. Please never include passwords or tokens.
• Privacy and deletion requests: privacy@laya.net.
• Support: in the app, open Help and support and choose Contact support, or email support@agilepulse.co.