Turn a work retrospective into a next-period plan you can check
Retain the initial version of one improvement and append execution and evidence reviews; distinguish completion from effects and decide what comes next.
On this page
A useful review identifies what happened, which explanations need checking, and how to inspect one proposed change next time. Compare evidence with the goal, choose a worthwhile action, then specify ownership, dates, dependencies, acceptance, and follow-up.
This exercise turns fictional progress material into a fact-and-explanation table, one proposed improvement, and a complete report. Use the in-article record to retain your own initial version and append execution, evidence, and next-step decisions later. Action completion and observed effects stay separate. An action awaiting approval remains a proposal.
Reconcile the plan and actual progress
Original fictional teaching material: the overall configuration task contains 12 units. Eight in this week's plan were due by the agreed check-in; six are complete and two await interface information. The exact effect on Friday's demo and the full causes remain open. There are no measurements of customer waiting or efficiency. Today, tomorrow, and Friday are relative exercise times; replace them with actual dates when adapting the material.
| Layer | Supported statement | Unsupported conclusion |
|---|---|---|
| Fact | Six of eight units are complete at the check-in; two await information | All weekly goals were met |
| Goal gap | Two planned units remain incomplete; the weekly completion rate is 75% | Overall completion is also 75% (the overall denominator is 12) |
| Possible explanation | Check information dependencies and how they were confirmed | The interface team is the sole cause |
| Business impact | Friday's demo scope may be affected; exact impact is open | Customer waiting has fallen or a demo delay is confirmed |
Retain the original goal's timing and definition. If a goal was subsequently changed with approval, record the original, change, approval, and effective date before comparing results. A revised target should not conceal the original gap.
Choose one retrospective approach
KPT helps organize what to keep, problems to address, and changes to try. YWT draws learning from what you did before choosing what to do next. This example uses KPT to focus on work improvement; filling both tables is unnecessary.
| KPT item | Example | Status |
|---|---|---|
| Keep | Propose retaining progress updates against the agreed check-in | Proposal; effectiveness unmeasured |
| Problem | Eight planned, six complete, two waiting for information | Fictional fact; root causes unknown |
| Try | Confirm required information, contacts, and expected availability before the next cycle | Improvement hypothesis; agreement and approval needed |
Earlier dependency checks might expose gaps; they do not guarantee that information arrives on time. A Try is not an action already taken. One review cannot establish a universal best practice.
Make the proposed change inspectable
Proposed action: check required interface information and availability before the next configuration cycle starts.
| Element | Proposed content |
|---|---|
| Purpose | Expose dependencies and unknowns earlier, without promising to eliminate delays |
| Action and output | List information, use, contact, expected availability, confirmation status, and record location |
| Owner and deadline | Confirm with the project lead; replace “before starting” with an actual date and time |
| Dependencies and effort | Information from relevant contacts; effort cap still to be agreed |
| Acceptance | Check that required information for the next cycle's scope is listed; unknowns have follow-up actions and are not marked available |
| Follow-up | At the next agreed check-in, inspect plan/actual progress, information status, and added checking effort; timing still open |
| Decision and status | Not approved or performed; decide whether to continue, adjust, or stop after follow-up |
Acceptance has two layers. Checking that the list is usable examines the action's output. Checking subsequent delivery examines its effect. Completing a list does not establish better efficiency. Changes in scope, complexity, or staffing also limit causal conclusions from a before-and-after comparison.
Retain the initial plan and append a follow-up
Original case: still a proposal
Eight units planned, six completed, two awaiting interface information. Earlier dependency checks are proposed; ownership, deadline, effort, and approval remain open. There is no execution or effect record.
Follow up one action in your own material
No action selected
State the owner, actual dates, acceptance, effort limit, and follow-up method. Leave unagreed details open. Recording a proposal does not grant agreement.
Review the complete record
Personal improvement and follow-up record; facts, agreement, and judgments are supplied by you Full original, before fixing the initial version: Period, original target version and timing: Actual results, denominator, evidence and unfinished work: Gap: Possible causes, contrary evidence and unknowns: Reason for choosing KPT or YWT: Practice to retain or learning (status and evidence): One proposed change, purpose and output: Owner, date and time, dependencies and effort cap: Separate output acceptance from effect observation: Approval, implementation and observed-result status: Follow-up timing and continue/adjust/stop conditions: Proposed; agreement pending Follow-up draft not yet appended: Execution unknown Effect unmeasured Next step undecided Timestamps are browser recording times in UTC, not actual agreement or review dates; state actual dates and evidence locations in your text. Completing an action does not establish an effect, and before/after change alone does not establish causation.
Personal material is saved separately by language in this browser. It is not uploaded or translated. Clearing site data deletes it; keep a downloaded copy and avoid editing it in multiple tabs. Review checks reset after changes.
A complete review update
At this week's agreed check-in, eight configuration units were planned and six were complete; two await interface information. The 12-unit overall task is not this week's denominator. The gap is two units, while full causes and the exact Friday demo impact are still being checked.
We propose confirming required information, contacts, and availability before the next cycle to expose dependencies earlier. The owner, actual deadline, and effort cap need agreement; the change is not approved or performed. First check the list and follow-up arrangements for unknowns. At the next agreed check-in, inspect delivery status and added effort before deciding whether to continue, adjust, or stop. Current material does not establish an efficiency improvement.
A short report retains the gap, explanation status, proposed action, and approval state. Keep the detailed list for questions. If the purpose is simply progress awareness, start with the concise-update example without adding an unnecessary improvement proposal.
Complete a review of your own
Choose a real period and retain the target version, actual results, evidence, and unfinished work. Select one change worth the effort and identify observations that could support or challenge it. Paste a complete retrospective or plan above, select one action, and label agreement according to the actual response. Retain that initial version, then append later agreement, plan changes, observations, and unfinished work as follow-ups. Earlier entries stay intact. The practice pack remains available. The reporting tool's review mode lets you organize results, explanations, learning, and plans manually. Include the owner, effort and approval status, leaving unagreed details open.
Practice materials
- Blank outline, fictional statement and practice checksTXT · 2 KB
- Fictional progress facts and pending improvement proposalJSON · 1 KB