Most retrospectives produce a warm feeling and a list nobody reads again. This one starts with the numbers so the conversation has something to argue with, forces every proposed change to carry a name and a date, and then makes you report back on what you actually did about last period's list.
How to use this tool
Fill in the numbers for the period that just ended — what you committed to, what you finished, what you estimated in hours and what it really took. The tool computes completion rate, estimate ratio and carry-over.
Add items to the three lists: what worked, what did not, and what you will change.
Every change item needs an owner and a by-when date. Anything missing either gets tagged a wish, not an action. That tag is the whole point of the tool.
Work through the carry-over section — last period's changes, each with an honest status. This is the part real teams skip, and skipping it is why their retros stop mattering.
When the period is over, use Archive this period. Your change list becomes next period's carry-over list automatically, so you cannot quietly forget it.
The test that matters: if someone read only your change list, could they tell who would be embarrassed if it did not happen, and on what date? If not, you wrote a mood, not a plan.
Every control is a button, a select or a form field. Nothing requires dragging or a mouse.
How this maps to Jira and similar trackers
Mapping between this tool and common tracker vocabulary
Here
Jira
What people say out loud
Period
Sprint (Scrum board) or a date range on a Kanban board
"this sprint", "the iteration"
Committed
Sprint scope at start, shown on the Sprint Report
"what we pulled in"
Completed
Completed Issues; the points total is your velocity
"we did 14 points"
Carry-over
Issues Not Completed, rolled to the next sprint
"spillover", "it rolls"
Hours estimated / spent
Original Estimate vs. Time Spent (worklogs)
"the estimate was garbage"
Change with owner and date
Its own issue, assigned, with a due date
"action item"
Sprint report
Jira's sprint report lists what was completed, what was not, and — the line people skip — what was added after the sprint started. Scope change is usually the real story. A team that "missed the sprint" often hit everything it planned and then absorbed three urgent items nobody counted.
Velocity, and why comparing it between teams is meaningless
Velocity is the number of story points a team completes per sprint, usually reported as a rolling average of the last three to five. It is useful for one thing: that team forecasting its own next few sprints.
Points are a local currency. Each team calibrates its own sense of what a 3 is, against its own codebase, its own on-call load, its own definition of done. There is no exchange rate. Team A doing 40 and Team B doing 20 tells you nothing about either — and when a manager starts ranking teams by velocity, the number inflates within about two sprints, because inflating it is far easier than shipping more. You will see this happen. Say so carefully, but say so.
Burndown charts
A burndown plots remaining work against days left, with a straight "ideal" line for reference. Real burndowns are stair-shaped, because work completes in lumps. Two patterns are worth reading: a flat line that falls off a cliff on the last two days means everything was finished at once, which usually means everything was started at once; and a line that jumps up mid-sprint means scope was added. Some teams prefer a burn-up chart precisely because it shows scope as its own line instead of hiding it.
How retrospectives actually get run
Typically 45 to 90 minutes at the end of a sprint, with a facilitator who is often not the manager. Common formats: start / stop / continue; mad / sad / glad; the 4Ls (liked, learned, lacked, longed for). The format matters much less than people think.
Honest version: a large share of teams run retros as ritual. The same three complaints appear every time, nothing changes, attendance drifts, and eventually someone proposes doing them monthly instead — which is how a retro dies. Two things separate the ones that work. First, they leave with a very small number of changes — one or two, not eight — each with a named owner and a date. Second, they open the next retro by reading those out loud and saying what happened to each. That second habit is what this tool is built around, and it is the one almost nobody does.
One more piece of vocabulary you will hear: blameless. It does not mean nobody is accountable. It means the question is "what about our system let this happen" rather than "whose fault was it" — because in a room where the answer might be your name, people stop reporting problems, and then you lose the data.
1. The numbers for the period just ended
Fill these in before the discussion, not after. A retro that starts from memory becomes a retro about whoever remembers most confidently.
2. The retro
What worked — keep doing it
Be specific enough that someone could repeat it on purpose. "Good teamwork" is not repeatable; "we paired on the migration script for two hours instead of reviewing it afterwards" is.
What did not — stop it or fix it
Name the thing, not the person. The useful form is "what about how we work made this likely".
What we will change next period
This is the list with teeth. Every item needs one named owner and one date. Keep it to one or two items — a retro that produces eight changes produces none.
3. Carry-over accountability
Last period's changes, each with an honest status and one line on why. Archiving a period copies its change list here automatically. This section is the credibility of the whole exercise: a team that never checks its own action items is holding a support group, not a retrospective.
Follow-through counts done as one and partly as a half. Dropped counts as zero — dropping a change on purpose is a legitimate decision, but it is still a change that did not happen, and pretending otherwise is how the number stops meaning anything.
Fill in the numbers, then add items to the three lists.
What this retro says
Enter the period numbers and a few retro items, and observations will appear here.
4. History and trend
Completed periods, oldest first. The current period is shown last and marked in progress until you archive it.
Period
Dates
Committed
Completed
Completion rate
Estimate ratio
Follow-through
Archiving stores the current period, copies its change list into the carry-over section of the new period, clears the working fields and suggests the next period's name and dates. Nothing is deleted.
One more question
The numbers above cannot reach this. The gap between what a team knows and what it says in the retro is usually where the real problem lives.
Keep your work
This tool remembers your work in this browser on this device. Nothing is sent anywhere.