Trust and security: SprintPoker for Azure DevOps

SprintPoker for Azure DevOps is a planning poker extension for Azure Boards, from the Visual Studio Marketplace. Its sessions, votes and AI hints run on our own servers: your data is stored in London (UK) and processed in Stockholm (Sweden), on Amazon Web Services. Its AI hints 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 SprintPoker for Azure DevOps. Compare all six apps.

At a glance

Architecture and data flow

How SprintPoker for Azure DevOps 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 SprintPoker for Azure DevOps in Azure Boards, signed in to Azure DevOps.
2. The extension gets the person’s Azure DevOps identity, and a short-lived access token for them, from Azure DevOps as it opens. On its General settings page it also turns its work item panel and its work item menu entry on or off for the project.
3. The extension, in the browser, calls our servers to run sessions and Quick Estimation (votes, estimates and comments), to ask for AI hints, and to read and change work items in Azure DevOps. Sent over HTTPS (TLS).
4. The browser keeps a secure WebSocket open to our servers for live updates in a session and in the Quick Estimation panel. Sent over Secure WebSocket (TLS).
5. Our servers read work items, project details and people’s profile pictures from Azure DevOps, and make the changes people ask for, as the person using the extension: with the short-lived access token the extension sends with each request, which our servers never save. In Azure DevOps: the estimates people save to a work item’s estimation field, and the changes people make to work items from SprintPoker, such as a new title, description, state, assignee, iteration or place in the backlog, a new child work item, a comment, or an image added to a description. Each change is made as the person who makes it. Sent over HTTPS (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 a session’s moderator asks for an AI hint, or starts or picks a work item with automatic hints on, in a session with AI features on: our servers send OpenAI only the fields listed under How AI is used. Never sent to OpenAI: any person’s account details from Azure DevOps, or their name except where it is written or @mentioned in a sent field (see below), Azure DevOps comments, attachments, votes, session comments, email addresses, or who is in a session. 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 SprintPoker for Azure DevOps 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 Azure DevOps user id of each person in a session, with the display name and picture address Azure DevOps showed, their votes and the comments they write in sessions; the same for each person who votes in Quick Estimation; and, for each work item in a session, its assignee’s display name and picture address.

In your Azure DevOps organization

• Azure DevOps itself: the estimates people save to a work item’s estimation field, and the changes people make to work items from SprintPoker, such as a new title, description, state, assignee, iteration or place in the backlog, a new child work item, a comment, or an image added to a description. Each change is made as the person who makes it.
• Azure DevOps project settings: whether the Quick Estimation panel and the work item menu entry show in the project, set from SprintPoker’s General settings page.

On our servers

• Sessions: the name and settings, the organization name and the project and team they belong to, the work items in them (each one’s id, title, type and the type’s icon address, state and priority, its assignee’s display name and picture address, and its current estimate), the Azure DevOps user id of the person who created it, votes (each with its voter’s user id, and in Async Poker their display name) and final estimates, comments written in the session, AI hints and up to four reference work items (id and title).
• People in a session: their Azure DevOps user id, and the display name and picture address Azure DevOps showed (where Azure DevOps gives no display name, their email address stands in for it).
• Quick Estimation, for each work item someone estimates from its form: the votes, with each voter’s Azure DevOps user id, display name and picture address, whether the votes are shown, and the final estimate.
• Project settings: each work item type’s estimation field and card values, named card presets (with the user id of the person who made each), the project’s reference work items (id and title), and whether the Quick Estimation panel and the work item menu entry show.

What we never store

• Work item descriptions, acceptance criteria, Azure DevOps comments and attachments: our servers pass them between Azure DevOps and the extension, and keep none of them in our database.
• Azure DevOps access tokens: the extension sends a short-lived one with each request, and our servers never save it.
• Email addresses: the people search passes them from Azure DevOps to the extension, and our servers save one only where Azure DevOps gives a person no display name, as that person’s name in a session or a Quick Estimation.
• Profile pictures: our servers fetch them from Azure DevOps for the extension to show, and keep each in memory for up to an hour, never in our database.
• The prompts sent to OpenAI: each is built for one request and deleted straight after.

How AI is used

AI runs on our servers, not on Azure DevOps. 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 account details from Azure DevOps, or their name except where it is written or @mentioned in a sent field (see below), Azure DevOps comments, attachments, votes, session comments, email addresses, or who is in a session. Text people typed into the fields that are sent, such as a name written in a description, is sent as typed, and an @mention in a description is sent as the person’s display name (“@Display Name”).

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: each AI hint with its session, in our database with no expiry (see "Retention and deletion").

Turning AI off

SprintPoker for Azure DevOps has no setting today for an administrator to turn its AI features off for a whole organization or project. Each session’s creator chooses whether it has AI hints: Enable AI Features, when the session is created, is on by default, and the session’s moderators can change it later in Session Settings.

In the extension, only a session’s moderators can ask for an AI hint, and automatic hints run only when a moderator starts or picks a work item in a session that has them on. Nothing runs on a schedule.

Where data is held

Your data is held in Europe: stored in London (UK) and processed in Stockholm (Sweden). When someone asks for an AI hint, the text sent is processed by OpenAI in the United States. Where your Azure DevOps organization is hosted does not change where our servers keep data.

Connections outside Azure DevOps

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 extension is uninstalled: the extension has no uninstall step.
• Deletion: Deleting a session in the extension marks it deleted, and the record stays in our database. Resetting a Quick Estimation clears its votes. Nothing expires automatically.
• Closed accounts: The extension has no step that removes a person whose account is closed or who leaves your organization: their user id, display name and picture address stay in past sessions and Quick Estimations.
• Logs: Our servers log each request that fails, with the full address requested (which can hold search words), the referring page, the browser’s user agent and the IP address it came from. Some warnings also record the Azure DevOps user id, organization and session involved, and the words of a people search that Azure DevOps could not answer. Those application logs have no set retention period yet. The web server’s access logs, which also hold IP addresses, are kept for 14 days.
• Deletion requests: to ask for your organization’s data to be deleted, email privacy@laya.net.

Security practices

• Only encrypted connections: the extension reaches our servers only over https and wss.
• Changes to Azure DevOps are made as the person who asked for them, so Azure DevOps’s own permissions apply.
• Our servers never save an Azure DevOps access token: the extension sends a short-lived one with each request.
• Encryption: Connections are encrypted: the extension reaches our servers only over https and wss, our servers reach Azure DevOps and OpenAI over https, and our servers reach the database over TLS, which MongoDB Atlas requires for every connection. One exception: our servers fetch a profile picture over http when its address, or a redirect from it, uses http. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.

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: email support@agilepulse.co.