Documentation

Run a team retrospective

How SquadBear's retro board moves through its stages, blind brainstorm and voting, and what closing freezes

Every participant opens the retro board on their own device.

Where it lives

Open Team health → Retrospectives. The list badges the running board In progress and files the rest under Other active, History, and Upcoming (drafts with a scheduled date). Team leads, managers and admins create one.

New retrospective opens the dialog: Title, Team, Template, Icebreaker, Votes per participant (default 5), and four checkboxes - Anonymous contributions, Blind brainstorm, Blind voting and Allow stacked votes - all on by default.

The stage flow

A retro walks one hop at a time: check-in, brainstorm, group, vote, discuss, review. The facilitator advances with Next and can step back one stage; closing is separate.

Check-in opens with Open actions to review - the team's open and in-progress actions, whatever created them; Mark done completes the same action Improvement actions tracks. The facilitator edits or removes the icebreaker until check-in ends; a later change is refused with a 409. In group, Suggest merges clusters ungrouped cards that repeat each other against the workspace's daily AI budget; a human accepts each cluster. At discuss, the facilitator's focused card or group lights up on every open board.

Blind brainstorm and blind voting

Blind brainstorm hides peers' cards while people write - each writer sees their own cards plus a per-column count ("2 peer cards hidden") until group reveals every card. Blind voting hides running tallies until discuss; a voter's own dots and budget stay visible. The server-side projection enforces both: a hidden card's text, id and author reach no surface, API and MCP included. Neither toggle changes after creation.

Attribution

Anonymous contributions gives an anonymous board; clearing it gives a named one. create_retro_session takes all three modes and defaults to alias, a per-session pseudonym. An anonymous board ships no participant names, so the participant rail has no remove control; update_retro_participants removes someone and deletes their cards and votes. Every mode stores a hashed vote author: a voter sees their own, everyone else the aggregate tally.

Vote budgets

Supplying Votes per participant pins the budget; omitted through create_retro_session, it derives when voting opens - one vote per three cards and groups, clamped to 3-10. The facilitator resets it (1-20) on the vote stage. Allow stacked votes lets one person put several votes on one item; with it off each item takes one vote per person, unless voting opens with fewer topics than votes, which turns stacking on.

Closing a retro

Closing snapshots the tallies, participation count, column counts and ranked ordering, rotates every author hash to a fresh random value, and deletes the raw votes. Only a retro in discuss or review closes by hand; there is no undo. A nightly cron closes any board past draft whose stage last moved over seven days ago the same way. The closed board is read-only; Generate summary writes the AI recap once and caches it.

Worked example

Marta opens a Start, Stop, Continue retro for Northlake's five-person Platform team and keeps the dialog defaults - anonymous, both blind toggles on, five votes each. She advances to discuss, focuses the top-voted group, then closes from there.

The flow runs over create_retro_session, set_retro_stage, add_retro_cards, cast_retro_vote, set_retro_discuss_focus, suggest_retro_actions (read-only) and close_retro_session; get_retro_session polls live state.