Sprint Review vs Retrospective
Two events sit an hour apart in most teams' calendars, and what separates them is not the agenda. It is who is in the room.
A review is about the product and faces outward. A retrospective is about how the team works and faces inward. Everything else follows from those two facts, including the reason that combining them, which looks like an efficiency, removes most of the value of one of them.
Three axes, and the audience is the one that matters
Subject. A review looks at what was built: whether it does what was wanted, what it revealed, what should come next. A retrospective looks at how the building went: what got in the way, what the team should do differently, what is worth trying in the next cycle.
Output. A review produces a decision about the work ahead, usually a change to the order of things, taken by somebody with the standing to take it. A retrospective produces a change to how the team operates, decided by the team, and small enough to be done by the next cycle.
Audience. A review needs people from outside the team, because without them there is nothing to review against; a team reviewing its own product against its own expectations has held a meeting. A retrospective needs those same people to be absent, because what makes it useful is somebody saying the thing they would not say in front of a stakeholder. Section 5 of the PMBOK® Guide Eighth Edition treats facilitation and group techniques as project tools, and the composition of the group is the first setting on any of them.
What each one goes wrong as
A review goes wrong as a demonstration. The team shows what it built, people say it looks good, nothing changes, and everybody leaves on time. The test is straightforward: could the order of the next cycle's work have changed as a result of this meeting, and was somebody present who could change it? If not, what took place was a demo with a misleading name, and demos are worth doing and are a different thing.
A retrospective goes wrong as a list. The team produces observations, the observations are written down, and the next retrospective produces the same observations, which has its own treatment and a short version: one change, done, beats six recorded. The harder failure happens before any of that, when somebody from outside is in the room and the conversation quietly reduces itself to the things that are safe to say.
Four months of communication could be better
A bank's change programme had combined the two events into a single ninety-minute session at the end of each fortnight, for sensible reasons: diaries were full and the two seemed related. The business sponsor attended, which also seemed sensible, because he was engaged and wanted to see the work.
The review half was good. He gave clear feedback, changed the order of two items, and caught a misunderstanding about a reporting requirement that would have cost a fortnight.
The retrospective half produced, across four months, one recurring observation: communication could be better. Nobody was being evasive. The team's actual impediment was that requirements arrived from the sponsor's own team about four days later than the team needed them, every cycle, so the first two days of each fortnight went on something else and the last two were compressed. Saying that in front of him was not a conversation anybody wanted to start at half past four on a Friday.
Splitting them cost nothing. Thirty minutes of review with stakeholders on the Thursday, forty-five minutes of retrospective without them on Friday morning. The requirements timing surfaced in the first ten minutes of the first separated session, and it turned out to be fixable: the analyst moved her own deadline forward by a week, and the sponsor's team, asked directly, said they had never realised the date mattered.
The sponsor heard about the change afterwards, from the delivery manager, which is the right route. A retrospective without stakeholders is not a secret meeting. It is a meeting whose output goes to them rather than whose conversation happens in front of them.
The same two functions exist on predictive work under different names, and they fail identically. A stage review that has become a report to a board, with no decision available at it, is a demonstration. A lessons learned session held at the end, producing a document nobody will open before the next project starts, is a list. Neither problem belongs to agile delivery and neither is solved by changing method.
For a PMP® candidate, it helps to recognise that each event has one job and one audience. A team whose retrospectives produce nothing, with a stakeholder in attendance, has the cause sitting in the description. A review where nobody present can change anything is describing a decision that happens somewhere else. The question to put to any event is who is in the room and what they are able to decide. Practising where the meeting exists and the function has gone is what a structured PMP exam preparation course turns into routine.
Take each event in turn and put one question to it. For the review: what changed as a result of the last three? For the retrospective: what did the team do differently after the last three? Two questions, six answers, and the pattern in them is usually clear inside a minute.
Interested in going further?
Combining the two saves an hour a fortnight and costs the only meeting in which a team can say what is actually wrong. Omega's PMP® Exam Preparation works through situations where the event exists and its purpose has quietly gone.
Group and facilitation techniques have their own place in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A187: Retrospectives That Lead to Change
A191: Product Backlog vs Sprint Backlog
A180: Facilitation Techniques for Difficult Project Conversations
A178: SWOT Analysis in Project Management
A182: Multicriteria Decision Analysis Explained
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
