Turn retrospective evidence into a prioritized improvement backlog
Connect feedback and exit interviews to proposed changes. Display impact and effort estimates so the team can choose a small set of improvements and turn them into assigned tasks.
How this works
Connect feedback and exit interviews to proposed changes. Display impact and effort estimates so the team can choose a small set of improvements and turn them into assigned tasks.
Turn retrospective observations into a small, owned set of improvement experiments. Separate the problem evidence from suggested solutions and keep impact and effort estimates provisional until the team validates the assumptions.
When period work records are available, prepare a short evidence sheet before the discussion. Keep completed, accepted or shipped, returned for rework and carried-over items distinct so the team can test recollections against records.
Before you start
Defined operating scope
Retrospective feedback needs to become a small set of evidence-backed changes with agreed owners.
Required source material
Obtain Retrospective notes and participant feedback; Team priorities and delivery constraints. If connectors are unavailable, use authorized files with the same fields.
Decision and exception rules
Feedback suggests a solution without evidence of the problem. Ask for an example and keep the proposal exploratory.
Prepare the inputs
- feedback_batch
- Required
Retrospective notes and participant comments
Keep the relevant context and permitted attribution.
- team_priorities
- Required
Current objectives and constraints
Use the agreed planning period.
- candidate_rules
- Required
Problem, impact and effort definitions
Separate evidence from estimation.
- owner_capacity
- Required
Available roles and capacity
Do not assign commitments without confirmation.
- period_work_records
- Optional / conditional
Dated task or delivery records, state transitions and acceptance evidence.
Optional corroboration for the selected period. Preserve closed versus accepted/shipped distinctions and repeated transitions on one item.
- period_measure_rules
- Optional / conditional
Cutoff, state definitions and any locally meaningful effort measure.
Use only for comparable period summaries. Do not compare velocity across teams or infer individual productivity from ticket counts.
Implementation, step by step
Establish the working record
- Confirm the selected records, effective versions and responsible owner.
- Check feedback_batch, team_priorities, candidate_rules, owner_capacity before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.
- If preparing a pre-meeting sheet, freeze the period and its work-record cutoff. Participant feedback remains valid input when no task system exists.
Checkpoint: The input record identifies the selected feedback_batch and any missing required fields.
Extract specific problems and retain the evidence behind each one
- Extract specific problems with examples and distinguish repeated issues from repeated comments about one event.
- Check each backlog item links a concrete problem to evidence and a proposed mechanism.
- Group work by business theme and list returned items with their recorded reason. Treat repeated returns on one item as events, not automatically independent problems.
Checkpoint: A saved intermediate result for: Extract specific problems and retain the evidence behind each one.
Draft proposed improvements and provisional impact and effort estimates
- Draft bounded improvements with expected mechanism, provisional effort and a way to observe whether the problem changes.
- Verify selected tasks have confirmed owners and distinguish estimates from measured effects.
- Use the evidence sheet to pose discussion questions, such as which acceptance step was missed. A pattern suggests an investigation; it does not prove one person or process caused it.
Checkpoint: A saved intermediate result for: Draft proposed improvements and provisional impact and effort estimates.
Review and reorder the candidates with the team
- Review candidates with the team, resolving conflicting perspectives and reordering priorities using explicit assumptions.
- Check each backlog item links a concrete problem to evidence and a proposed mechanism.
- Reconcile disputed totals and preserve dissent. Counts of closed, shipped and returned items can overlap; declare whether rows describe end-state snapshots or event history.
Checkpoint: A saved intermediate result for: Review and reorder the candidates with the team.
Create tasks only for the changes the team agrees to take on
- Create tasks only for selected improvements with confirmed owners, next steps and a review date.
- Verify selected tasks have confirmed owners and distinguish estimates from measured effects.
Checkpoint: A saved intermediate result for: Create tasks only for the changes the team agrees to take on.
Package the result and unresolved work
- The team validates the interpretation, effort estimates, and commitments. Do not turn every suggestion into an assigned task automatically.
- Do not turn every suggestion into an assigned task.
- Keep the pre-meeting sheet separate from the team’s selected improvement backlog. Record which evidence supported, contradicted or left each proposed change uncertain.
Checkpoint: A prioritized improvement backlog with evidence and confirmed owners. Unresolved items remain visible in the review record.
Decisions along the way
Feedback suggests a solution without evidence of the problem.
Ask for an example and keep the proposal exploratory.
Impact or effort estimates conflict.
Record ranges and assumptions, then let the team choose what uncertainty to reduce.
No owner has capacity for a selected change.
Keep it uncommitted and revisit scope or priority rather than assigning silently.
A work item was closed, returned and closed again in the same period.
Count one unique item, retain both transitions and apply the agreed snapshot rule. Do not inflate completed-item counts with repeated closures.
What you will produce
retrospective-to-improvement-backlog-result.json
JSONA prioritized improvement backlog with evidence and confirmed owners. Label proposed and completed states separately.
Include: problem · evidence · proposed_improvement · impact_assumption · effort_estimate · team_priority · owner · review_date · status · evidence_reference · review_note
retrospective-to-improvement-backlog-review.md
MarkdownKeep the evidence and unresolved decisions needed to apply this result, including exceptions involving owner_capacity.
Include: source_reference · question · owner · next_action
retrospective-evidence-sheet.md
MarkdownOptional preparation for discussion; not a verdict or automatic task list.
Include: period · cutoff · state_definitions · business_themes · unique_items · returned_items · carry_over · evidence_gaps · discussion_questions
Check the result
- Check each backlog item links a concrete problem to evidence and a proposed mechanism.
- Verify selected tasks have confirmed owners and distinguish estimates from measured effects.
- Inspect feedback_batch and team_priorities in both the original and output; confirm that record identity and interpretation survived the transformation.
- The team validates the interpretation, effort estimates, and commitments. Do not turn every suggestion into an assigned task automatically.
- Reconcile distinct items separately from state-transition events and explain overlapping categories.
- Check any period comparison uses the same team, definitions and cutoff rules; leave missing baselines unknown.
When something goes wrong
Feedback suggests a solution without evidence of the problem.
Ask for an example and keep the proposal exploratory. Retain the affected evidence and recovery status.
Impact or effort estimates conflict.
Record ranges and assumptions, then let the team choose what uncertainty to reduce. Retain the affected evidence and recovery status.
No owner has capacity for a selected change.
Keep it uncommitted and revisit scope or priority rather than assigning silently. Retain the affected evidence and recovery status.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Turn retrospective evidence into a prioritized improvement backlog for the following bounded example; prepare the result for review.
Inputs
Synthetic example: Three participants describe missed handoffs from one launch. Suggested fixes are a new tool and a short checklist; no evidence compares them. Optional board evidence shows five unique work items: three accepted, one returned after being marked closed, and one incomplete at the cutoff.
Expected result
Synthetic expected result: Create one handoff problem with three references. Propose a small checklist trial and a separate tool hypothesis; the team selects one owner-confirmed experiment. The preparation sheet reports three accepted, one awaiting rework and one incomplete under its stated end-state rule, then asks which handoff check could have detected the omission. It does not present five items as five delivered outcomes.
Run a small pilot
Start small
Trial a representative batch containing the ordinary case and the exception demonstrated above.
Record the baseline
Record current preparation time, review effort and correction types for the same records.
Agree success criteria
Agree acceptable review and error limits; measure agreed improvements with supporting evidence; completion and rework after the review.
Stop or revise
No owner has capacity for a selected change. Pause affected records and apply this recovery: Keep it uncommitted and revisit scope or priority rather than assigning silently.
Keep the scope clear
- Do not turn every suggestion into an assigned task.
- Preserve dissenting or minority feedback without exposing confidential participant details.
Check before using
The team validates the interpretation, effort estimates, and commitments. Do not turn every suggestion into an assigned task automatically.
Business activities
- Coordinate meetings and follow-ups
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Retrospective notes and participant feedback · Team priorities and delivery constraints · Optional period work records and state definitions
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow