How to Run a Sprint Retrospective in Linear (Step-by-Step)
Linear Cycles (sprints) generate useful completion data that serves as the foundation for retrospectives. At the end of a cycle, Linear shows completed vs. incomplete issues, team velocity, and individual throughput. Using this data in retrospectives grounds the discussion in facts rather than perception.
This guide covers running a sprint retrospective with Linear cycle data, from pulling the right reports to converting retro insights into next-cycle action items.
Step-by-step guide
Review the cycle completion data
Before the retrospective, navigate to your team's Cycles view and select the completed cycle. Linear shows: total issues completed, total issues carried over, story points completed (if you use estimates), and cycle time by issue. Take a screenshot of this summary to share in the retrospective.
Complete the cycle in Linear
At cycle end, Linear automatically archives the cycle and moves incomplete issues back to the backlog or to the next cycle based on your team settings (configure in Team Settings > Cycles). Ensure this happens before the retro so the team sees finalized completion numbers.
Analyze carry-over issues
Review every issue that carried over from the cycle. For each one, ask: was this overscoped from the start, did it get blocked by a dependency, or was it genuinely unexpected work? Pattern-matching across multiple cycles reveals systematic planning problems that individual sprint data masks.
Review issue cycle time
In Linear Analytics (available on paid plans), review cycle time: the median time from "In Progress" to "Done" for issues in this cycle. Cycle times that spike are early signals of coordination problems, unclear requirements, or scope creep on individual tickets.
Run the retrospective discussion
Use a separate collaborative tool (Miro, Notion, or a shared doc) for the brainstorming phase. Three questions: What helped us move fast? What slowed us down? What will we change in the next cycle? Reference specific Linear issues where relevant — "ENG-47 took 8 days in review" is more actionable than "code review is slow."
Create action items as Linear issues
For each committed improvement, create a Linear issue: "Set up automated PR review assignment" in the next cycle. Assign it to a specific engineer with a due date within the cycle. Retro actions that live only in a Notion doc get deprioritized during sprint planning.
Track retro effectiveness over multiple cycles
Keep a running list of retrospective actions and their completion status. After 4-5 cycles, review this list: how many actions were completed? What recurring issues keep showing up? This meta-retrospective shows whether your retro process is actually driving improvement.
Common mistakes
Running the retro without cycle data visible
Retrospectives without data devolve into "I felt like this sprint was okay." Pull the Linear cycle summary and have it on screen for the first 10 minutes of the retro.
Creating too many action items
Three action items per retrospective is the maximum. More than three means the team cannot focus on any of them. Better to commit to one thing and do it than five things and do none.
Not assigning action items to the next cycle
Retro actions left as Notion notes or Linear Backlog issues never make it into the next sprint. Assign action items to the next cycle immediately during the retro meeting.
Tips
Use Linear's cycle notes feature to add a retrospective summary directly to the completed cycle
Filter Linear issues by "Created this cycle but not completed" to find scope that crept in mid-sprint
Track velocity trend in a running spreadsheet — Linear does not currently have a built-in velocity chart across cycles
Share the Linear cycle link in your team Slack channel before the retro so everyone reviews it independently first
How Vantage helps
Vantage's bi-directional Linear sync tracks which tickets were pushed, modified via sync, or rejected. This data reveals which PRD requirements needed rework in engineering — a retrospective input that improves future PRD quality.