How to run a retrospective on a shared board

A retrospective is one meeting with a short shelf life, which makes it an awkward fit for a permanent project tool and a very good fit for a board you can throw away afterwards. Here is a setup that takes about a minute.

What the meeting is for

The twelfth principle behind the Agile Manifesto is that a team should stop at regular intervals to reflect on how to become more effective, and then adjust how it works. The Scrum Guide makes that a named event, the Sprint Retrospective, whose purpose is to plan ways to increase quality and effectiveness, and which it timeboxes to at most three hours for a one-month sprint (for shorter sprints, it says, the event is usually shorter).

The practical consequences of that are the two things most retrospectives get wrong. It is timeboxed, so gathering the raw material during the meeting wastes most of the box. And the output is a change to how the team works, so a retrospective that ends with a list of feelings and no owned actions has not finished.

Setting up the retrospective board

Create a board, name it after the sprint or the date, and pick a 14-day lifespan rather than the 60-day default. That is not a limitation to work around; it is the useful part. The board deletes itself long before it becomes a graveyard nobody remembers agreeing to, and there is no cleanup task afterwards.

A new board arrives with To Do, In Progress and Done. Rename them from each column menu and add a fourth. Four columns that work:

  • Went well — keep doing this
  • Did not go well — the observations, not the blame
  • Ideas — anything somebody wants to try
  • Actions — the only column that survives the meeting

Start / Stop / Continue and Mad / Sad / Glad are the same shape with different labels, and both work fine here. What matters is that the final column is for committed actions and nothing else, so that at the end of the hour you can look at one column and know what changed. More on the general principle in the guide to choosing columns.

Gather the material before the meeting, not during it

Send the link and the password two days ahead and ask everyone to add cards as things occur to them. This is the single biggest improvement available to most retrospectives: the quiet half of the team gets to think, and the meeting starts with material instead of silence.

If people send you notes instead, open Create, choose Paste a list, pick a column and paste them one per line. Bullet characters, numbering and checkbox markers are stripped, so a pasted chunk of meeting notes turns into cards without editing. Up to 200 lines go in at once.

Because there are no accounts, nobody has to be invited and nobody signs up to contribute. Anyone with the link and the board password can add cards, which is the right level of ceremony for a meeting that lasts an hour. It also means everyone can edit everything, so if that is a problem for your group, read on to the sharing section.

One thing to know before the meeting: the board does not push other people's changes to your screen as they happen. If several people have it open at once, reload to pick up what everyone else added. In practice this only matters during the silent reading phase, and one reload at the start of the discussion is enough.

Grouping without a whiteboard

Cards take a colour from a set of seven, or a custom hex value. Use it for themes rather than for sentiment, since the columns already carry the sentiment: one colour for deployment pain, one for meetings, one for anything about the codebase. Once ten cards are up, the colours make the clustering obvious without anyone having to physically move stickies around.

Running the hour

  1. Read in silence for five minutes. Everyone has the board open. No discussion yet.
  2. Group and dedupe. One person drags near-identical cards together and deletes the duplicates while the others talk.
  3. Discuss the top few themes only. A timebox forces this. Three themes discussed properly beats eleven mentioned.
  4. Write the actions as you go. A card in the Actions column, one owner named in the title, a due date set on the card. If it has no owner and no date it is an idea, and it belongs in the Ideas column where it can be honest about itself.

For an action with several steps, put them in the card description as markdown checklist lines — - [ ] draft the runbook — and they render as tickable boxes with a progress count, so you can see how far an action got before the next retrospective.

Sharing the outcome without letting anyone rewrite it

A manager or a neighbouring team usually wants to see what came out of the meeting, and usually should not be able to edit it. Copy a view-only link from the Share menu instead of the edit link: it needs no password, opens the same columns and cards read-only, and can be revoked later. The differences are covered in the guide to edit links and read-only links.

Keeping the record

The board expires and cannot be extended, so before it does, export it. JSON and CSV are both in the board menu; CSV is the one to use if the actions are going into a spreadsheet or a ticket tracker, since each card becomes a row with its column, title, description, colour and due date.

For the next retrospective, duplicate the board with Include cards switched off. You get the same four columns and the same password on an empty board, which saves renaming three columns again. Note that a duplicate always starts a 60-day lifespan and there is no way to shorten it, so if you want the 14-day expiry back, create the next board from scratch instead.

Things that reliably go wrong

  • One person typing. If the facilitator is the only one with the board open, you have run a meeting with extra steps. The link and password exist so that everybody has it open.
  • Actions with no owner. A card titled improve testing is a wish. A card titled Priya: add a smoke test to the deploy job with a date on it is an action.
  • Carrying everything forward. Most cards in Did not go well are meant to be read once and dropped. Only the Actions column deserves to survive, and letting the board expire enforces that better than good intentions do.
  • Putting sensitive material on the board. Anyone with the link and password can read all of it, and performance conversations about named individuals do not belong there.