Write estimates back to Jira

When a moderator accepts an estimate on a work item that came from Jira, SprintBee can write that number straight onto the Jira issue. Write-back is off until you map at least one field, and it is configured per Jira source rather than per session.

Before you start#

• A paid plan. Work item integrations are a Pro capability, and so is write-back. Set this up from the account that owns the paid organization — that owner's plan is the one SprintBee resolves entitlements against.
• A Jira source already saved on the Workspace. The field dropdowns are populated by asking your Jira site what fields exist, which needs a saved source to ask through. Until then the section reads "Save this Jira source first".
• A connection that can write. Personal OAuth connections need the write:jira-work scope. Connections authorized before write-back existed do not have it, and the section shows a read-only banner until you reconnect.
• Edit permission on the target fields in the projects you estimate, for whichever identity the connection uses.

Turn on write-back#

1. Open the Dashboard, choose the Workspace, and go to Integrations & notifications.
2. Scroll past "Bringing work in" to Sending results back, and find Story point write-back.
3. Tick Write accepted story points back to the Jira issue. The field dropdowns appear once SprintBee has loaded the site's fields.
4. Choose a Story points field. Every dropdown lists each field with its type — Story Points (number), T-Shirt Size (select), and so on — and system fields are marked as such.
5. Select Save write-back.

The setting belongs to the Workspace's Jira source, so every Planning session that Workspace runs inherits it. There is nothing to switch on inside the room.

Map Dev and QA separately#

Rooms that estimate Dev and QA independently can send each figure to its own field. Tick This room estimates Dev and QA separately to reveal three more dropdowns, then map any combination of them:

Dropdown	Receives
Dev estimate field	The accepted Dev estimate
QA estimate field	The accepted QA estimate
Dev + QA total field	Their sum, only when both are numeric

Leave any of the three on "— Don't write —" to skip it. The total is genuinely conditional: if either role's accepted card is not a number, no total is written, even though the individual fields still are.

Which fields can receive a value#

SprintBee looks up each mapped field's type at write time and formats the accepted value to match it. A value the field cannot hold is dropped rather than forced.

Field type	Accepts	Notes
Number	Numeric estimates only	A T-shirt size is silently skipped
Text	Any estimate value	The safest target for non-numeric decks
Select	Any estimate value	The value must exist as an option in Jira

Anything else — a date, a user picker, a multi-select — is ignored, so mapping one has no effect.

Cards that mean "no estimate" are never written to any field, whatever its type. That covers ?, ∞ and ☕. Other non-numeric cards, including T-shirt sizes and a Pass card, are real values and will be written to a text or select field.

What triggers a write#

Write-back runs once, on its own, when a round is accepted:

• A moderator accepts an estimate in a live session.
• An async voting window closes and converged rounds are auto-accepted.

It only runs for items imported through the Jira connection. Items captured by the Browser Companion or pasted in as a bare issue key are references, not connected issues, and are never written back.

The write is best-effort and never blocks the session — accepting an estimate returns immediately and the outcome catches up a moment later. Updates made through a personal connection are attributed in Jira to the Atlassian account that authorized it; updates through the shared Jira app are attributed to SprintBee.

Confirm it worked#

Each attempt is recorded against the round, and the work item shows a chip once points have been accepted:

Chip	Meaning
Points synced	Jira accepted the update
Sync failed	Jira rejected it; hover for the reason
Not synced	Nothing was eligible to write

The chip stays with the item in History, so you can check a session after the fact rather than watching for it live.

When points do not reach Jira#

Sync failed#

Jira returned an error. The message Jira gave is carried through to the chip's tooltip, and it is usually a permission or validation problem: the connected identity cannot edit that field in that project, or the field rejects the value's shape.

Jira rejected the update. Reconnect Jira to grant write access, then try again.#

The connection does not hold write:jira-work. Reconnect it from the Dashboard's Integrations tab, using the same Atlassian account, and approve the current set of permissions.

Not synced#

Nothing was written, and Jira was never called. Check, in order:

• Write-back is ticked on for this Workspace's Jira source.
• At least one field is mapped — the toggle alone writes nothing.
• The accepted card is a real estimate, not ?, ∞ or ☕.
• The mapped field can hold the accepted value. A T-shirt size against a numeric field produces exactly this outcome.
• The item was imported through the connection, not captured or pasted.