How to turn retrospective action items into Linear issues

Not every retrospective note needs to become an issue. A reflection can be valuable context, appreciation or a question for discussion. Publish an action when the team has agreed a concrete next step that belongs in its work tracker.

Write a short title that describes the change. Add the observation behind it, an owner and a review date. For example, “Trial a release handover note” can include what information support lacked and which release will test the new approach.

Check whether a suitable Linear issue already exists before creating another. If the team is already tracking the work, use that issue as the shared reference rather than splitting updates between duplicates.

A facilitator can open the board’s Linear connection controls and connect through Linear. Check the verified account and workspace shown after returning to Retro. Signing in to Retro and configuring a board’s publishing destination are related steps, but do not assume that sign-in alone chooses where its issues should go.

Choose the team, an optional project or cycle, and the statuses to use for open and completed actions. Review the choices before saving them, especially if you belong to multiple workspaces or work across several teams.

The destination should match the people who will actually do the follow-up. A retrospective improvement sent to an unrelated project can be just as easy to lose as an action left only in meeting notes.

Open the action items and review the issue details. Confirm the title, description, assignee details and any priority or labels you intend to use. A board participant’s display name is not proof of a matching Linear account, so check the resulting assignment.

Use Publish for the selected action when it is ready. Creating a board or writing a note does not automatically publish an issue. After publication, open the linked issue and check its destination and content before considering the handover complete.

For an example action, the description might say: “Support received release context after customer questions arrived. Try a three-bullet handover before the next release, then ask support whether it covered what they needed.” This preserves the reason for the change alongside the task.

Retro checks linked Linear issues for updates. Publishing and using Sync action send changes from Retro to Linear; editing a note is not a blanket instruction to overwrite its linked issue. Use the connection panel’s update check when you need to refresh the latest state.

If both versions have changed, review the conflict before choosing how to resolve it. Read the actual differences rather than assuming the newer timestamp has the better answer. A colleague may have added delivery context directly in Linear while the team refined the experiment on the board.

Keep the retrospective available for the next review. Completing an issue tells you the task is done; the retrospective can still ask whether the change helped.

Retro also offers a Linear CSV export with import guidance. Review which open or completed actions to include, choose the intended team and project during import, and check the imported issues afterward. The CSV route is a separate handover rather than the board’s live connection.

Avoid importing the same file repeatedly or both importing and publishing the same action without checking for an existing issue. A repeated import can create duplicates. Keep one clear tracking reference for each agreed action and return to its outcome at the next retrospective.