Play one session with SprintPoker for Jira

A SprintPoker session of Jira issues can be available in both apps: one session, played from Laya.net and from SprintPoker for Jira on the Jira site its issues come from. Everyone sees the same issue, the same votes and the same results, whichever app they use. Once SprintPoker for Jira is connected for a Jira site, every new session of its issues is in both apps, whichever app it is created in.

Before you start

1. Someone on the Jira site connects it to Laya.netThey start it in SprintPoker for Jira: anyone who uses SprintPoker on the Jira site can, unless a Jira admin limited it. SprintPoker for Jira shows a code and opens Laya.net with it. The code works once, for 15 minutes.
2. Someone approves it on Laya.netThe page names the Jira site and shows the code, so you can check it is the one SprintPoker for Jira shows. One Jira site goes with one Laya.net workspace, its Laya.net home: the workspace that already has the site’s Jira connected. When the site has a Laya.net home, the page offers only that workspace. If you aren’t in it yet but your own Atlassian account can open the site, the page offers a Join button for it: you join the workspace (as an Admin when Laya.net confirms you are a Jira site admin, otherwise as a Member), then approve the code there. When the site has no Laya.net home yet, choose a team workspace (Jira sites connect to team workspaces, never to a personal one): approving also connects the site’s Jira to it (its boards and issues, for everyone in the workspace), and Atlassian asks you to allow it first, then the page finishes. If SprintPoker for Jira is already on as the site’s Jira connection for Laya.net, the page says so instead: approving connects the site’s Jira through the app, and there is nothing else to allow (see SprintPoker for Jira as the workspace’s Jira connection). Press Approve. Approving needs permission to add connections in that workspace (Members have it by default), and your own Atlassian account must be able to open that Jira site. If it can’t yet, the page offers Continue with Atlassian (Connect your Jira access when your account is already linked) first and brings you back; the code still works afterwards, within its 15 minutes. A Jira admin’s disconnect frees the pairing, but the next code still goes to the site’s Laya.net home; moving the site means moving its Jira connection first.
3. New sessions show in both appsFrom then on, every new session of the site’s Jira issues is in both apps: one created on Laya.net shows on the SprintPoker for Jira dashboard, and one created in SprintPoker for Jira shows on Laya.net. Sessions that already existed stay as they were: their hosts can still make them available in both apps.

The same code can also be entered by hand: in SprintPoker settings, on the Connections tab, under Link a Jira site, then Link this Jira site. A code typed there follows the same rule; when no workspace has the site’s Jira yet, approve it on the page SprintPoker for Jira opens. Inviting external guests from SprintPoker for Jira needs no connection at all: a host there can turn on guest access, and guests join on Laya.net with the session’s Laya.net link.

SprintPoker for Jira as the workspace’s Jira connection

Connecting SprintPoker for Jira to Laya.net also turns it on as the site’s Jira connection for Laya.net, whoever connects it (after the code is approved): a Jira admin’s connection uses the projects they choose (every project the site does not restrict from sharing, until they choose), anyone else’s only the projects where that person can edit issues (never one the site restricts from sharing; a Jira admin can add the others). A Jira admin can change the projects or turn it off in SprintPoker for Jira’s settings, and a site already connected keeps it off until a Jira admin turns it on. Laya.net then reads and updates the site’s issues through the app, so its boards stay in sync for everyone in the workspace without anyone’s personal Jira sign-in.

• Where the workspace has no Jira connection of its own, the app becomes it: approving the code connects it, with nothing else to allow.
• Where the workspace already has one, Laya.net keeps reading through it and uses the app when it can’t reach Jira. With a connection made with an Atlassian account (OAuth) or an API token, changes go through the app first; with Laya Board for Jira, the app is only the backup.
• Changes made on Laya.net show in Jira as SprintPoker for Jira, unless the person who makes them chooses to make them as themselves: the board’s You / SprintPoker switch, the same personal choice as for Laya Board for Jira. It covers changes made in SprintPoker sessions on Laya.net too.
• On a site where no Laya.net Jira connection can read issues for external guests, SprintPoker for Jira also reads for them, when they look, each issue’s description and the pictures in it, and the board’s Reference and Matching Issues where the host shares them: it never syncs a board, never makes a change and never stands in for the workspace’s connection, and it is not listed under How Laya.net reaches Jira.

In workspace settings, Integrations, Jira, How Laya.net reaches Jira lists each way Laya.net reaches the site, in the order they are tried, and which one carries the connection right now. A workspace admin can stop using the app there: Use the app next to the workspace’s own connection, Use as backup next to Laya Board for Jira. If the app was the workspace’s only Jira connection and a Jira admin turns it off or removes it, the connection shows Disconnected, with Open Jira and Connect with Atlassian to bring it back. SprintPoker settings, on the Connections tab, says where each site’s Jira data comes from.

Sessions in both apps

• When you create a session of Jira issues on a Jira site where SprintPoker for Jira is connected (see Before you start), Create Session shows Laya.net and SprintPoker for Jira under Sharing, and the session shows on the SprintPoker for Jira dashboard too. It is not a choice. The same goes the other way: a session created in SprintPoker for Jira on that site shows on Laya.net too.
• Where SprintPoker for Jira isn’t connected, the session is Laya.net only, and Create Session offers Connect SprintPoker for Jira to show sessions in Jira too: it opens SprintPoker settings in a new tab, and the form keeps everything you entered. Back on the form, it checks the connection again.
• The Jira site’s rules and your own Jira access are checked when the session is created: your own Atlassian account must be linked and able to browse every Jira project the session uses. If they don’t allow it, the session is created on Laya.net only and you see why, and you can try again from Invite in the session bar.
• Who can find it then starts at People who can see its Jira projects: SprintPoker for Jira lists the session for everyone whose own Jira access reaches its projects, and everyone in your workspace finds it and joins it on Laya.net. Choose Everyone in this workspace instead and SprintPoker for Jira lists it only for the people in it.
• For a session that is not in both apps yet (one created before, or one whose sharing was refused), open Invite in the session bar (it is called Sharing once the session is shared) and, on its Settings tab, turn on Available in SprintPoker for Jira. Only the host can.
• Only sessions of Jira issues can be shared, on the site those issues come from. Sessions of typed-in items or Laya boards stay on Laya.net. An async session is shared like a Poker session, unless Create Session says Async sessions can’t be shared yet.
• A workspace can keep sharing to its admins, or to some Jira sites; Create Session then shows Laya.net only to a host its rules keep out, and says why.

A session created since new sessions are kept in both apps stays in both apps: there is no switch to take it out of one, in either app, and the room says so. A session from before can still be turned off by its host or a moderator: that makes it Laya.net only again, and people playing from SprintPoker for Jira keep their seats, votes and results, but can’t act until it is turned on again. Nothing is deleted either way.

Who joins from where

The people panel shows where each person is playing: Laya.net, Jira (in SprintPoker for Jira), or Jira and Laya.net for someone who has it open in both, which is still one seat and one vote. A guest shows as Guest.

Sessions created in SprintPoker for Jira that are available on Laya.net appear on the SprintPoker overview when you have a seat in them or your own Jira access lets you see their projects. A public one also appears for everyone in the Jira site’s Laya.net workspace, who joins it straight away; a private one appears only for the people in it. In the Jira site’s Laya.net workspace they are in its own list and open inside it; on any other workspace’s overview they are under Shared with you, grouped by From Jira and the site. Open Session opens one. If you are not in it on Laya.net yet, the page says You are not in this session yet. with Join from Laya.net and Join as observer. When your Atlassian account is linked and you have opened the session in SprintPoker for Jira, your seat there becomes your one seat on Laya.net, even in a private session, and the vote you cast there comes with it. A finished one opens with its results, read-only.

The board comes too. When a session starts on a Jira board, Laya.net mirrors that board in the workspace (for a session created in SprintPoker for Jira, the site’s Laya.net workspace) when its Jira connection can see the project, so everyone in the workspace can open it. It happens in the background and is retried for a day; a board the workspace already mirrors is reused, and the workspace’s Audit log records each new one. In SprintPoker for Jira, Open in Laya.net (in Share, and in the room’s ⋮ menu) opens the session on Laya.net, where the room offers Open the board to the members of that workspace (in the session bar, or in the session’s ⋮ menu on a phone); it opens the board in a new tab.

Link your Atlassian account

Linking your Atlassian account makes you one person in both apps. Laya.net uses it to:

• count you once: without it, a seat you open from SprintPoker for Jira and your seat on Laya.net are two seats with two votes;
• save estimates to Jira as yourself with Save & Next;
• make a session available in SprintPoker for Jira, and show you the sessions shared from Jira.

Laya.net offers Link your Atlassian account wherever it is needed: in the room, and in SprintPoker settings under Personal, in Your identity. When your account is already linked but SprintPoker has no working Jira access of yours for a site, every place that needs it (the room, the people pickers, making a session available in SprintPoker for Jira, Link a Jira site and Your identity) offers Connect your Jira access instead: the same steps, for the same Atlassian account. When it is the Jira access your Atlassian sign-in gave Laya.net that stopped working, Connect your Jira access renews that access: one approval at Atlassian mends it for Laya.net’s boards and for SprintPoker alike, and brings you straight back. When a seat from SprintPoker for Jira looks like yours, the room says so: confirm it with Same person? Use one seat, or a moderator can Remove duplicate.

Issues you can’t see in Jira

Jira’s own permissions still apply. When Jira says your own Atlassian account can’t see one of the session’s issues, SprintPoker shows you a placeholder instead of the issue and notes that Jira doesn’t let you see it. That check is only for a Laya.net account from outside the session’s workspace: members of the session’s workspace, and members of the workspace whose Jira connection serves the session’s Jira site (they see what that connection sees, as on the workspace’s boards), get no placeholder. When Jira can’t say (you have no Jira access of your own that works, or Jira doesn’t answer), nothing is hidden.

• By default you can only abstain on such an issue: your hand holds just the Abstain card, even in a session whose deck has no Abstain card of its own.
• The host can turn off Abstain only on hidden issues in the session’s settings. Everyone can then vote on such an issue with any card, and the note says the host lets you. Only the host can turn it off; any moderator can turn it back on.

AI hints in shared sessions

In a session available in both apps, the AI hint is shared: Laya.net makes one hint per issue, once, and both apps show it word for word. A moderator in either app presses Show Hint, then Ask AI; everyone else sees the hint as soon as it is ready, and the Recommended Estimate appears only after the votes are revealed. Try again asks for a new hint for both apps. To make a hint, Laya.net sends the issue’s key, summary, description and Estimation Field to its AI provider.

A hint uses the AI allowance of the session’s workspace (for a session created in SprintPoker for Jira, its Jira site’s), as every hint on Laya.net does. When that allowance is used up, both apps say so in the hint, and Try again works once it has room again.

Where shared hints aren’t offered, both apps say why in place of Show Hint: AI hints aren’t available in shared sessions yet. when this Laya.net server doesn’t offer them yet, or AI hints are turned off by a Jira admin on this Jira site. The session’s Enable AI Features setting is kept either way. When AI is turned off for a shared session, both apps say AI hints are turned off for this shared session.

The Jira site’s rules

A Jira site administrator decides what the site allows. SprintPoker settings shows it under Set by a Jira admin: whether sessions can be shared at all, who can make Laya.net sessions available, whether external guests are allowed and what they may see, and whether AI hints are allowed. Choices in a session can only narrow these rules, never widen them.

If a Jira administrator disconnects SprintPoker for Jira from Laya.net, sessions created on Laya.net continue on Laya.net only. Sessions created in SprintPoker for Jira pause: they stay listed in SprintPoker for Jira and are read-only in both apps, and rounds that were still open wait with their votes hidden. When a Jira admin connects SprintPoker for Jira to Laya.net again, they carry on. Nothing is deleted. A disconnect doesn’t change guest access: each session keeps its guest choices, the guests of a paused session see it paused and read-only, and no new guest joins it while it is paused. New sessions in SprintPoker for Jira can still have guest access, as on a site that was never connected. Guest access turns off only when a Jira admin turns off Allow external guests in SprintPoker for Jira, or when a host turns it off for their own session.