I Like, I Wish, I Wonder

'I wish' is the same critique as 'this is broken' — phrased so the person who built it can hear it.

Three sentence stems: I like, I wish, I wonder. Built at the Stanford d.school for design critique, this is the retro to run straight after a demo or sprint review — 'I wish' turns criticism into a request the maker can hear, and 'I wonder' gives open questions a column of their own instead of forcing them into verdicts.

30 min315 peopleRemote-friendlyeasy

When to use

Right after a demo, sprint review, or design review — while the thing is still on the screen. This is the feedback format, not the process format: it points at an artifact, which is exactly why 'what went well / what didn't' feels wrong in that meeting — those columns point at the sprint. If the retro's subject is how the team worked, run Start/Stop/Continue or What Went Well. If the subject is what the team built, run this. It also holds up with stakeholders in the room — the stems do the tone-policing so you don't have to.

How it runs

  1. Run it while the demo is warm

    Same meeting, straight after the walkthrough — or the last twenty minutes of sprint review. Feedback on an artifact decays in a day; by tomorrow people remember their impression, not the details.

  2. Silent write, stems enforced

    Five to eight minutes. Every card starts with one of the three stems, first person. The stem is the format — the first bare 'this is broken' card that stands unedited tells the room the rule is optional.

  3. Read the Likes fast

    Likes are the keep-list, not a victory lap. Read them out, note what to preserve in the next iteration, move on. Five minutes.

  4. Cluster the Wishes

    This is the critique. Group duplicates, let the room talk, and keep the maker quiet — wishes get counted, not rebutted. Budget half the meeting here.

  5. Answer the Wonders, then convert

    Wonder cards are questions. Some die in thirty seconds ('yes, it handles timezones'); the rest become investigation items with a name attached. Close by picking the top two or three wishes and giving each an owner.

Why it works

The grammar does the work. 'I wish the setup flow were shorter' and 'the setup flow is too long' are the same critique — but one is a request and the other is a verdict, and the person who built the flow can only hear one of them. That's the d.school's design-critique insight: feedback in I-statements, phrased as desire, for rooms where the maker is present. The third stem is the quiet differentiator — every other mainstream retro column demands a judgment, so questions get dressed up as opinions or go unasked. 'I wonder' gives uncertainty a column, and what a team doesn't know is usually more useful than what it dislikes.

Variations

  • 'I like, I wish, What if' — the d.school original. 'What if' pulls proposals; 'I wonder' pulls doubts. Run What If when you want ideas for the next iteration, I Wonder when you want the unasked questions.
  • Sprint-review closer: last twenty minutes, stakeholders included. The stems keep external critique civil without anyone moderating.
  • Async: link the demo recording at the top of the board and give it 24 hours. Wonder cards double when people get overnight to think.
  • Add an 'I will' column when the same wishes reappear retro after retro — it converts the wish list into commitments on the spot.

Facilitator notes

Enforce the stems or don't run it — the phrasing rule is the entire format, and it dies the first time a bare complaint stands. Ask the writer to restate it as a wish; ten seconds, and it resets the room. Watch for verdicts wearing the stem: 'I wish someone had tested this' is a blame card, not a wish — redirect it at the artifact. And keep the maker silent through the Wish column (the design-critique rule the format was built around); they answer Wonders, not Wishes.

Pitfalls

  • Running it on process. 'I wish standups were shorter' belongs in Start/Stop/Continue — this format points at the thing you built.
  • Token Wonders — one vague card per person so the column isn't empty. Prime it: what wasn't in the demo, what happens at scale, what users will do that we didn't expect.
  • The maker rebutting every wish. Wishes get clustered and counted, not answered — a defended wish is the last honest one you'll get.
  • Scheduling it days after the demo. Impressions survive; details don't. Same meeting or next morning, nothing later.

Remote tips

Run it in the same call as the demo — the format is remote-native; the day-later follow-up meeting is what kills it. Paste screenshots of the demoed screens onto the board so wishes pin to something concrete instead of memory. If the review runs over, take the silent write live and cluster async — discussion can wait a day, card-writing can't.

Example outputs

  • I like that export is one click now — the old flow was four screens and we lost people on every one.
  • I wish the empty state said what to do first. I built half of this and still hesitated.
  • I wish the error named the field instead of saying 'invalid input'.
  • I wonder how the table behaves at ten thousand rows — the demo had twelve.
  • I wonder if support has seen this flow before it ships.

FAQ

When should I pick this over What Went Well or 4Ls?
When the subject is a thing, not a period. What Went Well and 4Ls point at the sprint; this points at the artifact you just demoed. If the agenda says 'discuss the release', run this. If it says 'discuss the fortnight', run those.
Where does the format come from?
The Stanford d.school, as 'I Like, I Wish, What If' — a rule for giving design critique in I-statements, built for rooms where the maker is present. Retro tools renamed the third stem to 'I wonder', trading proposals for questions. Both work; credit where due.
Can I run it every sprint?
As a sprint-review closer, yes — twenty to thirty minutes, stakeholders welcome. As your only retro, no: it never surfaces process problems, because it isn't looking at the process. Alternate it with Start/Stop/Continue.

Related activities

Recommended use cases