Warn a room about Prerequisites

Backlogs are full of work that has an order baked into it: the API before the screen, the migration before the feature. Jira and Linear already record that relationship, and SprintBee reads it so the room finds out at the moment it matters — when the item comes up to be estimated.

Nothing about it stops you. A Prerequisite warns and never blocks: the item still reaches the stage, still takes votes, and still accepts an estimate. The room decides what to do about it.

Before you start#

Prerequisites need a connected work item source, which is part of the paid Pro plan — SprintBee has to be able to read the relationship from the provider, so a typed-in work item never carries one.

Provider	What you get
Linear	Works as soon as the source is connected. Linear's relation set is native and fixed, so its blocks relation means exactly that.
Jira	Nothing until a workspace manager confirms a Prerequisite Link Mapping. See below.
GitHub	Not supported.

Reading the notice needs nothing special, and opening a Prerequisite in your provider is available to everyone in the room. Dismissing the notice is a moderator action. Pulling a Prerequisite into the queue is open to moderators and to anyone your workspace lets add work to a queue.

What a Prerequisite is#

A Prerequisite is a work item that your provider records as standing in the way of another one — Jira's "is blocked by" link, or Linear's blocks relation. SprintBee reads that relationship and never writes it. Creating, changing or removing a link is something you do in Jira or Linear, and the next read picks it up.

A Prerequisite is unmet while the item it holds up still cannot proceed. That is two different questions depending on where it lives:

• One sitting in this room's own queue is unmet by definition. Nothing in an open queue has been estimated yet.
• One outside the room is unmet while the provider still reports it unresolved.

A Prerequisite is not a Follow-Up. A Follow-Up is something a person in the room raised — a question the team still needs answered before it can put a number on the item, with a name against it if someone took it on. A Prerequisite has nobody behind it: it is news that arrived with the item. That is why the two appear in different places, the Follow-Up on the work item card and the Prerequisite above the votes.

The notice on the stage#

When a work item with an unmet Prerequisite takes the stage, a notice appears above the cast-votes pile naming what is in the way.

It says it in your tracker's words, not ours: if Jira calls the link "is blocked by", the notice reads "This work item is blocked by CRU-19". Rename that link type in Jira and the notice follows after the next read. Links imported before SprintBee started carrying the wording get a plain sentence that still names the item. Either way it is describing the relationship between two items, not the status of the one on the stage — a work item whose own status reads Blocked is a separate fact, and the status chip is where that one lives.

It is there before voting starts, not after. SprintBee renders what it last read straight away and then corrects it in place if a fresh read of the provider says something different — so the notice can change its mind a second or two in, and very occasionally disappear because the Prerequisite has since been resolved. That is deliberate. A notice that arrives late pushes the voting cards down the screen while people are already choosing one.

If the provider is slow or unreachable, the stored answer stands and is marked with when it was read. An outage weakens the warning rather than silently deleting it.

Open it in the provider#

Always available, to everyone. It opens the Prerequisite in Jira or Linear in a new tab, so somebody can read it properly while the room talks.

Pull it into the queue#

Moderators, and anyone allowed to add work to the queue, can bring the Prerequisite into the room to estimate first. It lands immediately before the item that prompted it.

This is refused when the Prerequisite lies outside the boundary of the room's source — another Jira project, another Linear team. You get the link-out instead. SprintBee will not mint a queue item to paper over a boundary it cannot read across.

Dismissing it#

A moderator dismisses the notice for the whole room, because the decision it asks for is the moderator's. It comes back when the item is made active again, and when the item's set of Prerequisites changes — a warning that has become a different warning is worth seeing twice.

The queue check#

Open Manage queue and the board tells you how many work items sit ahead of a Prerequisite of their own, and offers to reorder the queue so each one comes after it.

When the queue already runs in an order its Prerequisites allow — which is most sessions — the board says nothing at all. There is no badge, no banner and no empty state. This is a check with a repair, not a sort mode: the queue is still only ever reordered by an explicit moderator act.

The repair moves as little as possible. Every Prerequisite ends up ahead of everything that needs it, and the order you already had is preserved everywhere else, so pressing it twice produces the same queue as pressing it once.

Some queues cannot be fully repaired, and the board says so rather than quietly doing less than it claimed:

• A loop. Jira will happily let two issues each name the other as its Prerequisite. There is no valid order for those two, and one loop must not switch off the repair for the rest of the queue.
• A pinned first item. Once the item on the stage has votes, it keeps its place. If its Prerequisite is behind it in the queue, no reorder can fix that without throwing the votes away.

A Prerequisite that was estimated earlier in this session is in history, not in the open queue, and is not a violation. Its constraint was satisfied by happening.

Confirm a Prerequisite Link Mapping for Jira#

Jira link types are per-instance, renameable and extensible. "Blocks" is a convention on your site, not a contract, and SprintBee will not read meaning out of a name someone can change. So a Jira source renders no Prerequisite anywhere — not on the stage, not on the queue board — until a workspace manager says which link types mean it.

1. Open your workspace dashboard. If your imported Jira items carry issue links, a setup card is waiting there asking which of your link types record one item standing in the way of another.
2. Choose the link types. SprintBee pre-selects your site's stock Blocks type as a suggestion; confirming it is your decision, not ours.
3. Save. The card disappears, and Prerequisites start rendering on the next activation.

The same setting lives with the rest of the source's configuration under workspace Settings → Integrations, if you would rather go looking for it than wait for the card.

What this does not do#

Worth knowing before you go looking for it:

• GitHub is not supported at all. SprintBee's GitHub adapter has no concept of a link between two items, so a GitHub-only workspace sees nothing here. The setup card does not appear for it either.
• A Jira source shows nothing until its mapping is confirmed. Not a reduced version, nothing. Both the stage notice and the queue check depend on it.
• The web stage only. Prerequisites do not appear on the async ballot, in the Microsoft Teams app, or in the Browser Companion. The async gap is the widest of the three, because async voting is free on every plan — a team that estimates entirely on ballots gets none of this.
• A Prerequisite outside the queue is re-read only when its item takes the stage. Nothing tells SprintBee that your Prerequisite closed in the meantime, so its status can be up to one activation out of date. When the provider cannot be reached, the notice says when it was last read.
• Due dates are not part of this, and the queue check is not a sort. It enforces one rule — a Prerequisite comes before the item that needs it — and has no opinion about the rest of your queue.