Innovation sprint: review
Lesson preview: the Mini Lesson and Vocabulary are open to everyone. Guided practice, exercises, the parent checklist and the printable PDF worksheet come with full access (free 7-day trial or membership).
Learning Objectives
- 1Distinguish what worked from what needs improvement in a completed sprint
- 2Give and receive constructive feedback using a structured framework
- 3Identify the root cause of a problem that arose during the sprint
- 4Measure project success against the original goal and update documentation
Mini Lesson
An innovation sprint does not end when the demo finishes. The real learning happens in the review — a structured meeting where the team looks back honestly at what they built, how they worked together, and what they would do differently next time. Companies call this a "retrospective" (or "retro" for short). The goal is not blame — it is improvement. A good retro turns one sprint’s lessons into the fuel for the next sprint.
The two-column retrospective board
The simplest retro tool is a two-column board. On the left: "What worked" — things the team should keep doing. On the right: "What to improve" — things the team should change or fix. Every team member adds at least one card to each column. Then the group dot-votes on the most important items and picks one or two improvements to act on in the next sprint.
- WHAT WORKED — keep doing this (e.g. daily stand-ups kept everyone aligned)
- WHAT TO IMPROVE — change or fix this (e.g. scope was too large for the time box)
- Dot-vote to surface the highest-priority improvements
- Pick ONE or TWO action items so the team is not overwhelmed
Giving constructive feedback
Constructive feedback is specific, actionable, and kind. The classic format is SBI: Situation — describe the specific moment. Behavior — describe what happened, not who is at fault. Impact — describe the effect on the team or the product. For example: "During the Thursday prototype demo (Situation), the navigation crashed unexpectedly (Behavior), which meant we could not show the user flow to our testers (Impact)." Notice: no blame, just facts and consequences.
Receiving criticism professionally
Receiving feedback is a skill too. The professional response is to listen first, ask one clarifying question if needed, and say "thank you" — even if the feedback stings. Defending immediately or dismissing the feedback signals that the team is not safe to be honest, which kills future retros. Separate your identity from your work: the feedback is about the product, not about you as a person.
Finding the root cause
When something went wrong, the instinct is to fix the surface symptom. Root-cause analysis goes deeper. A useful technique is the "5 Whys": ask "Why did this happen?" and then ask "Why?" four more times on each answer. Example: the app crashed during the demo. Why? The database query was too slow. Why? The team used an unindexed table. Why? Nobody checked performance during sprint planning. Why? There was no performance-testing step in the definition of done. Root cause: missing checklist item — not a bad developer.
- State the problem clearly (what happened, not who is to blame)
- Ask "Why?" — write down the first-level cause
- Ask "Why?" again on that cause — write the second-level cause
- Repeat until you reach a process, tool, or decision gap (usually by the 5th Why)
- Fix the ROOT CAUSE so the same problem does not return next sprint
Measuring success against the original goal
A sprint has a goal set on Day 1. At the retro, the team asks: did we meet that goal? Be honest. If the sprint goal was "users can complete checkout in under 3 taps", measure that exact thing. Did any real user complete checkout in under 3 taps? If yes — success. If no — why not, and what changed? Measuring against the original goal keeps the team accountable and stops the finish line from moving mid-sprint.
Updating documentation and sharing learnings
The retro is only useful if its learnings survive past the meeting. After every retro: update the team’s process document (e.g. add the missing performance-testing step to the definition of done), archive the retrospective board so future team members can read it, and share a 3-line summary with any stakeholders who supported the sprint. Documentation turns a one-time insight into a permanent improvement.
Your sprint goal was "build a working prototype that a first-time user can navigate in under 2 minutes." During testing, users averaged 4 minutes. What should the retro focus on first?
The sprint goal gives a clear yardstick (2 min). The team failed to meet it. A good retro does not celebrate anyway — it diagnoses. Were the labels unclear? Was the user flow too long? Did the team test with real users early enough? Each answer points to a different root fix.
Warning: "we ran out of time" is almost never the real root cause. Keep asking Why until you reach the actual planning or scoping decision that created the time pressure.
Tip: end every retro with an explicit action item — who will do what by when. A retro with no action items is just a complaint session.
Unlock the full HSEA system for 7 days.
Add your first kid profile and your 7 days start: every lesson in every grade, saved progress for each child. Nothing to set up, no card required, nothing to cancel.
- ✓ All 1,680 lessons, Grades 1–6, every subject
- ✓ Profiles + saved progress for every kid
- ✓ Printable lessons with answer key