The Review That Became a Demo
Four-week Sprints, eight Developers, one Product Owner. Sprint Review: 30 minutes, the Product Owner demos finished features to four stakeholders, then closes the meeting; the Product Backlog is never shown and no one discusses what to do next. Retrospective: the engineering manager attends, opens with 'give me your status', and takes notes that feed performance reviews; Developers describe it as the only safe meeting. Daily Scrum: 25 minutes, Scrum Master asking each Developer what they did yesterday and what they will do today. Sprint Planning: one six-hour session on day one, with all refinement crammed into a two-hour session the day before.
1. Rank the four events from most to least fit for purpose, and justify each ranking by the event's purpose rather than by its timebox.
Read the worked answer
1. Retrospective - closest to fit. Its purpose (inspect how the last Sprint went regarding individuals, interactions, processes, tools and the DoD, then plan improvements) is being served: the Developers speak honestly and treat it as safe. The defect is who is in the room, not what the event does.
2. Daily Scrum - partially fit. It happens daily, it is short-ish, and it does inspect the work. But it inspects the wrong thing: activity rather than progress toward the Sprint Goal, and it addresses status to the Scrum Master rather than producing an adapted plan. Purpose half-served.
3. Sprint Planning - structurally fit, poorly executed. The event exists and covers 'what' and 'how' after a fashion. Six hours is within the timebox for a four-week Sprint, so time is not the issue - the issue is that a six-hour session following a two-hour refinement the day before means the team is discovering the work in the meeting. Purpose attempted, largely wasted.
4. Sprint Review - least fit. Its purpose is to inspect the Sprint's outcome with stakeholders and, together, determine what to do next; it is the Scrum Team's main adaptation point with the outside world. A 30-minute demo with the Product Backlog hidden and no discussion of next steps delivers none of that. It is a show, not an inspection.
Why this ordering matters: the repair plan differs. The Review needs redesign; Planning needs the refinement moved earlier, not a shorter meeting; the Daily Scrum needs a change of owner; the Retrospective needs a change of attendees only.
2. What is the specific harm of the engineering manager attending the Retrospective, and what are your options?
Read the worked answer
The harm is mechanical, not attitudinal. The Retrospective requires candour about failure. If notes from the meeting feed performance reviews, then anything said can be used against the speaker. Rational Developers respond by producing a safe, bland Retrospective - and they will be right. The event keeps its shape and loses its function, which is worse than cancelling it, because the organisation believes it is doing Retrospectives.
Options, in order of preference:
- Separate the purposes explicitly. The engineering manager gets delivery status through the Sprint Review, the Sprint Backlog, or a direct conversation with the Product Owner. Ask directly: what information do you need, and what is the least intrusive way to get it? Usually the answer has nothing to do with the Retrospective.
- Invite by agreement, with a rule. The Scrum Team can invite others when it serves a purpose - but the no-attribution rule must be stated and visibly honoured, and the manager must not run the meeting. If Developers are not convinced, this option fails regardless of the rule.
- Escalate if it persists. This is an impediment to the Scrum Team's effectiveness. The Scrum Master's accountability is to cause its removal; if the manager will not step out, escalate with the evidence (the Retrospective's output has become generic) rather than with the principle.
Do not simply bar the door without the manager's agreement - you get a meeting that is safe in the room and punished afterwards.
3. Planning takes six hours and refinement happens only in one two-hour session the day before. What does this suggest about how the team treats the Sprint Backlog, and what would you change?
Read the worked answer
Diagnosis: the Sprint Backlog is being produced, not evolved. The team discovers the work inside Planning because nothing was clarified beforehand; the six hours is not planning, it is analysis done in the wrong room with the wrong people. The Sprint Backlog then arrives as a fixed list to be executed, which is consistent with the Daily Scrum reporting yesterday's activity - nobody expects it to change.
Changes:
- Spread refinement across the Sprint. Small, frequent sessions (for example 45–60 minutes twice a week) beat one long session. Refinement is an ongoing activity, not a pre-Planning ritual; the new items clarified this week are what makes next Planning short.
- Set a Planning agenda against the three topics: why the Sprint is valuable (Sprint Goal), what can be done, and how the work will get done. Six hours with no Sprint Goal is time spent entirely on the middle topic.
- Make the Sprint Backlog visibly adaptable. Ask Developers at each Daily Scrum what changed in the plan. If the answer is always 'nothing', the plan is a contract, and the Daily Scrum has nothing to inspect.
Also worth checking: are refinement sessions attended by the Product Owner? If not, the two-hour session is the team guessing at intent, which explains both the length of Planning and the 'complete PBIs 101–118' style Sprint Goals.