Retrospective Analysis

See the pattern your retros keep circling

Paste your raw retrospective notes and Frankee reads across them for the things that are hard to spot one sprint at a time: themes that keep returning, issues raised repeatedly and never resolved, what is genuinely improving, and experiments worth running next.

What this is, and what it is not

This does not run your retrospective. The retro itself is the team's event: the conversation, the safety to be honest, and the decisions belong to the people in the room, and no tool should be between them.

What Frankee does is the part teams almost never get to. Notes are written every sprint and then rarely read again, so the same problem is raised in five consecutive retros without anyone noticing it is the same problem. Reading back across months of notes is exactly the kind of work that gets deferred forever, and exactly the kind a machine is good at.

Running an analysis

1. Open Retro Analysis

   Under Team Events › Retro Analysis, on the Analyze New Retro tab.

2. Give it a title

   Something you will recognise later, such as "Sprints 12 to 17" or "Q1 retrospectives". A title is required, because the analysis is saved and the history is only useful if entries are identifiable.

3. Paste your notes

   Raw and unedited is fine. Bullet points, went-well and went-badly lists, copy-paste from a whiteboard tool, action items, or plain prose all work. You do not need to tidy anything up or convert it into a format.

4. Analyze

   It takes a few seconds. The result is saved automatically and appears under View History.

Notes need to be at least a short paragraph. Anything shorter is refused rather than analysed, because a confident-sounding analysis of two lines would be invention.

This feature needs no tracker connection. It works entirely from the text you provide, so a team still deciding on Jira or Azure DevOps can use it today.

What you get back

Team health indicator

A single green, yellow, or red reading with a one-sentence summary of what drove it. It is a conversation opener, not a score: it reflects the sentiment and content of the notes you pasted, so it tells you how the team is talking about its work, not how the team is performing.

Treat a red as a prompt to ask what is going on, never as an assessment of anyone. Notes from one bad sprint can read red for a team that is fundamentally fine.

Recurring themes

Subjects that come up more than once, each with what the theme is about, how often it appears, and whether the team talks about it positively, negatively, or neutrally. This is where "we always seem to end up talking about the deploy process" turns into something you can point at.

Pattern analysis

For each topic, whether it is improving, worsening, stable, or new, with the evidence from your notes and how urgent it looks. Direction is the useful part: a problem that appears every sprint but is steadily improving needs a different response from one that is getting worse.

Unaddressed items

Things raised repeatedly that never seem to get resolved, with how many times they appear and why they matter. For most teams this is the section that stings, and it is usually the most valuable one. An item on its fifth appearance is not a team failing to notice a problem; it is a signal the problem is bigger than a retro action item can fix.

Wins

What genuinely improved, with the evidence and why it matters. Deliberately its own section, because retros skew toward what went wrong and improvements that go unacknowledged tend to quietly stop. If your team fixed something three sprints ago and stopped mentioning it, this is where that shows up.

Suggested experiments

Concrete things to try next, framed as experiments rather than fixes. Each one has:

• A hypothesis, in "if we do this, then that will happen" form.
• An action, specific enough to actually start.
• A measure, so you can tell afterwards whether it worked.
• Effort and impact, each rated low, medium, or high.

The measure is the part worth insisting on. A retro action with no way to tell whether it helped is how teams end up running the same experiment repeatedly without learning anything. Effort against impact is there so a team can pick the cheap high-impact one rather than the ambitious one that never starts.

Facilitator notes

A short read on what a Scrum Master should watch for. Useful for preparing the next retro: things to make space for, or dynamics worth being careful with.

History

Every analysis is saved to the View History tab with its title, date, and health reading, so you can look back at what the team was working through in a given period and whether the experiments moved anything.

Getting more out of it

• Analyse in batches, not per sprint. Every four to six retros gives Frankee enough to find real patterns. Running it after every single retro mostly returns a summary you already have in your head.
• Paste the notes, not a summary of them. Specific complaints are what make themes detectable. Summarising first removes the signal.
• Keep the notes verbatim, including the awkward parts. Sanitised notes produce a sanitised analysis.
• Re-run after acting. Add the next few retros and see whether the topic moved from worsening to improving. That is the closest thing to knowing your retros are working.
• Anonymise if your team would prefer it. Themes and patterns come through fine without names attached.