Planning workshop

Recommended owner: Product/business team member (product owner, product manager or delivery lead), co-led by a technical lead. Planning waste touches both sides so the facilitation must too.

Goals

What the team will do during the workshop:

1. Inventory the sprint’s meetings and classify each by purpose.
2. Walk the sprint’s key decisions and identify which were made too late.
3. Map external dependencies and the waits they caused.
4. Root-cause the top three planning waste sources and commit to actions.

Impact

What the team will walk away with:

1. A clear picture of how the team’s calendar time is spent and which of it is value-adding.
2. Named meetings converted to async docs, cancelled or shortened.
3. A plan for pulling important decisions earlier in the sprint.
4. Explicit agreements with upstream/downstream parties to reduce turnaround friction.

When to run this workshop

The planning workshop is the hardest of the three because planning waste is diffuse — it shows up across meetings, late decisions, external dependencies and roadmap thrash, often all at once. Reach for it when the readout shows planning as the dominant category and the team can’t point at a single fix; the workshop’s value is in surfacing the shape of the diffuse waste and routing each piece to the right corrective action.

Reach for it when:

• The readout’s planning hours are the dominant or co-dominant category — and especially when context-switching hours are also elevated, since the two reinforce each other.
• The team feels busy but can’t say what shipped — the SWOT opener and the meeting audit usually surface why within the first hour.
• External dependencies are visibly slowing the team — security reviews, platform-team work and vendor turnaround. Exercise 4 is built to map the friction and produce SLAs the team can take to the dependency owner.
• Stakeholder behavior is shifting under the team’s feet — roadmap changes, mid-sprint scope churn and escalations. The External intrusion bucket and the Force Field Analysis on actions are the protective layer for this case.

Don’t reach for it when the readout traces most planning hours back to rework or automation (route to those workshops first — fixing upstream usually dissolves the planning waste) or when the team has bandwidth only for a 45-minute session — use the Lightning Decision Jam as the substitute instead.

Audience and personas

Facilitator

Product owner or delivery lead. Has the whole-team view of how time gets spent — meetings, sprint commitments, blockers and external dependencies. Co-facilitated by a tech lead who can speak to the planning-to-implementation seams.

Required participants

• Product owner and any product-adjacent roles (BA, UX)
• Tech lead and 2–3 engineers
• Scrum master
• Anyone who runs a recurring meeting the team attends

Optional but valuable

• Representative of the most common external dependency (security, legal, platform team, partner vendor)
• Stakeholder or customer proxy (for the decision-timing exercise)

Roles

The four planning-waste buckets

Teach these in the opening.

Overlap with other workshops

Planning waste often sits on top of problems the other two workshops address:

• A team with lots of rework will have lots of fix meetings. Fix the rework, the fix meetings go away. See the rework workshop.
• A team with heavy manual work will have coordination meetings to orchestrate the manual work. Automate the work, the coordination vanishes. See the automation workshop.

If a meeting or planning problem traces back to a rework or automation root cause, send it to the matching workshop. This workshop should focus on planning-specific problems: when decisions happen, how they’re communicated and the seams between teams.

Pre-homework

Reading (for all participants)

• Event storming workshop — the structural exercise we’ll use for decision timing.
• Solve delivery with a steel thread — “answer the tough questions first” is the antidote to late planning.
• The 30-minute guide to Domain Driven Design — context boundaries help explain why dependencies friction happens.
• How to use a playbook — framing: guides are scaffolds, tailor them.

Individual prep (~30 min)

Each participant brings:

1. Their past-sprint calendar with meetings labeled by recurring vs. one-off.
2. A one-line description of every meeting’s purpose as they understand it.
3. A list of every wait or blocker they hit on external parties this sprint (who, how long, what was the ask).

Team prep (done by co-facilitators, ~30 min)

• Pull planning/waiting hours from the readout’s planning page.
• Pre-stage the event-storming wall with the sprint timeline (dates or sprint week).
• Prepare the decision-inventory template and the dependency template.

Materials and setup

• Large wall, whiteboard or Miro/Mural board (event storming needs space)
• Sticky notes in four colors:
  • Orange: events (what happened)
  • Blue: commands/decisions (what we chose to do)
  • Pink: problems or hotspots
  • Yellow: dependencies (people or systems we waited on)
• Markers and dot-vote stickers
• Shared doc for action items
• The readout’s planning and context-switching pages

Agenda (3 hours — longer than the others because planning waste is diffuse)

Workshop exercises

Framing exercise — SWOT on the planning process (20 min)

Run this before the numbered exercises. SWOT surfaces the team’s own assessment of its planning process before the data-driven exercises begin — participants engage with data more honestly when they’ve named the problem in their own words first.

Frame the four quadrants specifically around planning: Strengths (what works about how we plan — ceremonies, docs, decisions we make well), Weaknesses (late decisions, meetings that don’t decide, scope churn), Opportunities (what we could change that’s within our control — better pre-work, async docs, different cadence), Threats (forces acting on us from outside the team — stakeholder availability, external dependencies, vendor turnaround, organization-level change).

Silent fill (5 min), share back (10 min), then a 5-minute scan for patterns. Weaknesses and Threats populate the rest of the workshop’s hunt; Opportunities feed directly into action items; Strengths are named to protect — don’t reform them away by accident.

Full structure, facilitator script and worked example → SWOT analysis.

Use it as: The opener. It warms the team up, gives permission to critique and prevents the later exercises from feeling like a pure blame hunt.

Exercise 1 — Meeting audit (20 min)

Each participant lists every meeting they attended this sprint. Scribe captures on stickies:

• Meeting title
• Duration
• Attendees (approx count)
• Stated purpose

Calculate meeting hours: duration × attendee count. That’s the team-hours spent, not just one person’s time.

Exercise 2 — Classify meetings with TRIZ reframe (15 min)

Sort each sticky into one of four purpose categories:

• Decide — a decision was expected and (ideally) made
• Sync — align on status, plans or coordination
• Inform — one-way information transfer
• Fix — address a problem that shouldn’t have happened (bug triage, unplanned scope discussion, stakeholder escalation)

For each sticky, ask:

1. Was the stated purpose achieved?
2. Could the purpose have been achieved in a different format? (async doc, Slack message, recording, dashboard)

TRIZ reframe (add 10 min if time allows)

Invert the question to surface sabotaging behaviors: “What could we do to guarantee we have the maximum number of useless meetings?” Typical answers: “invite everyone to everything,” “never publish agendas ahead of time,” “treat attendance as a loyalty test,” “run decision meetings without decision-makers present” and “book recurring meetings that never get reviewed.” Then ask: “which of these are we doing right now?” — and watch the room go quiet. The admissions become input to the action-items exercise.

Full walkthrough → TRIZ.

Expected output: Meeting hours by category, plus the list of “inform” or “fix” meetings that are candidates for elimination or async replacement, plus a TRIZ list of sabotaging behaviors the team has admitted to.

Common outcomes:

• 40%+ of meeting time is “sync” and “inform” — a lot of it can go async.
• “Fix” meetings are an expensive symptom — they appear because something upstream broke. These route to the rework workshop or automation workshop.
• “Decide” meetings where no decision got made are a planning-waste red flag — the decision wasn’t teed up properly.

Exercise 3 — Strategic event storming of sprint decisions (45 min)

A compressed form of the event storming workshop — same sticky colors (orange = event, blue = command/decision, pink = hotspot) but narrowed from whole-product scope to the sprint’s planning and delivery flow.

Setup (5 min)

Draw a horizontal timeline on the wall (sprint week 1 → 2 → close). The co-facilitator explains the color scheme and the goal: map the decisions that shaped the sprint and find where they happened late.

Event storm (25 min)

The tech lead walks the sprint’s key flow. The team captures events, decisions and hotspots on the timeline. Examples:

• Orange (events): “PR merged to main,” “stakeholder sent new requirement” and “staging deploy.”
• Blue (decisions): “we chose to refactor,” “we deferred the observability work” and “we re-scoped story X.”
• Pink (hotspots): “three hours lost figuring out intent,” “surprise dependency discovered Thursday.”

Analysis (15 min)

Walk the timeline and ask, for each blue decision:

1. When was it made? (Mark with the timeline position.)
2. When could it have been made? (Place a marker at the earliest reasonable moment.)
3. What was the cost of that gap? (Rework, waiting and scope-shuffle — capture on pink stickies near the decision.)

The pattern you’re looking for: decisions that could have been made at sprint planning but were made mid-sprint. That gap is quantifiable waste.

Exercise 4 — External dependency mapping (20 min)

On a separate section of the wall, for each external party the team interacted with this sprint:

• Who/what (security, legal, platform team, vendor)
• The ask (what the team needed)
• Turnaround time (first request → response)
• Number of round-trips (how many back-and-forth cycles)
• Total team hours lost to the wait

The facilitator asks:

1. Was this dependency predictable? Could we have filed the ticket at sprint start?
2. Did the ask carry enough context, or did the back-and-forth come from ambiguity? (If yes, send it to the rework workshop.)
3. Is there a standing agreement with this party (SLA, escalation path) that could reduce turnaround?

Exercise 5 — Root cause on top three (30 min)

From the meeting audit, decision-timing exercise and dependency map, pick the three highest-cost planning waste sources. Break into groups of 3, one per source. Each group runs 5-whys.

Expected terminal root causes (collected from past waste walks):

• Meeting overhead: “We never decided what ‘done’ means for this meeting.” “Attendance is defensive — people come because they’re afraid of being out of the loop.”
• Late planning: “Our sprint planning doesn’t surface architectural risk.” “The PO doesn’t have a steel-thread view of the work.” “Key stakeholders aren’t available until week 2.”
• External dependencies: “We don’t file requests at sprint start because we don’t know what we’ll need.” “No agreed-upon turnaround with the security team.” “We route ad hoc through a single person instead of the intake process.”
• External intrusion: “We don’t have a routing or triage mechanism for mid-sprint requests, so they all land on the team directly.” “We say yes by default because saying no feels political.” “There’s no shared agreement with stakeholders about what constitutes an emergency.”

Exercise 6 — Action items with Force Field Analysis (20 min)

For each root cause, draft an action using the template below.

Before the team commits to each action, run a brief Force Field Analysis on it. Kurt Lewin’s insight: every change is a tug-of-war between driving forces pulling for it and restraining forces pulling against. If the restrainers outweigh the drivers, the change doesn’t stick. Draw a horizontal line representing the proposed change. Above the line, list driving forces. Below the line, list restraining forces. For each restraining force, ask: can we weaken it? If not, revise the action — don’t commit to something that won’t stick.

Use it as: A 2–3 minute check per action before naming an owner. Protects the workshop’s output from the “generated actions, shipped nothing” failure mode. Full walkthrough, worked example and common failure modes → Force Field Analysis.

Action-item template

Example actions

Capturing results

Within 24 hours, the scribe produces:

1. Meeting inventory with hours per category.
2. Sprint decision timeline (photograph or export the event-storming wall).
3. External dependency map with turnaround times.
4. Action-item list with owners and review dates.

Follow-up

• Facilitator checks in mid-sprint: did the removed meetings stay removed? Did the “tough questions first” pass catch anything?
• Next waste walk: meeting hours in the readout should be lower. Planning hours should be concentrated earlier in the sprint rather than late.
• Share meeting-removal wins publicly. They model the behavior for other teams.

Anti-patterns to watch for

• Cancelling meetings without replacing the function. If a meeting exists to unblock a decision, cancelling it without another mechanism makes things worse. Replace, don’t just remove.
• “One more meeting to solve the meeting problem.” A single retro is fine. If you’re scheduling recurring “meeting reduction” meetings, you’ve missed the point.
• Blaming external parties. External friction is usually bidirectional. Ask what the team could do differently to reduce turnaround (better ask, more context, earlier filing).
• Confusing process ceremony with planning. Standups, retros and planning ceremonies are not automatic waste. The question is whether your version of each is sized and run well.

When 3 hours isn’t available

If the readout points at one specific planning problem rather than diffuse waste across all four buckets, swap the full workshop for a Lightning Decision Jam (LDJ) — AJ&Smart’s eight-step, ~45-minute structure that collapses a retrospective-style session into strict time-boxes, most of them silent. Pair it with this workshop’s Force Field Analysis step on committed actions.

LDJ is a shorter substitute when full workshop bandwidth isn’t available — not a replacement for the full workshop when the readout shows diffuse planning waste across all four buckets.

Alternative and complementary exercises

Swap these in when the standard agenda doesn’t fit, when a specific bucket dominates or when the team needs a forward-looking variant.

Pre-mortem — forward-looking variant (20–30 min)

Imagine next sprint failed specifically on planning. Work backward from that imagined failure: what must have gone wrong? Surfaces planning risks before they happen. Pairs well with this workshop’s backward-looking event storm — the workshop identifies what did go wrong; the pre-mortem identifies what could go wrong next sprint.

Use it as: A 20-minute extension, or a separate session 1–2 weeks out. Full walkthrough → Pre-mortem.

Journey mapping — one story from idea to production (30–40 min)

Pick a representative story from the last sprint and walk its journey end-to-end on a timeline. Journey mapping surfaces the seams between roles and contexts — it is especially good at showing the team that planning waste often shows up as waits, not as events. A story that spent 3 days in “ready for review” is a planning signal, not just a code-review signal.

Full walkthrough, worked example and the emotional-layer technique that distinguishes journey mapping from pure process mapping → Journey mapping.

Use it as: Substitute for the strategic event storming exercise (Exercise 3) when one specific story illustrates the problem clearly.

1-2-4-All (facilitation pattern, Liberating Structures)

Applicable to any of the silent-brainstorm steps in this workshop. The pattern — 1 minute alone, 2 minutes in pairs, 4 minutes in fours, full-group share — prevents dominant voices from anchoring the discussion and is especially valuable for mixed-seniority teams or remote/hybrid sessions. Apply to Exercise 1 (meeting audit) and the root-cause brainstorms if the room is uneven in speaking time. Full walkthrough → 1-2-4-All.

Impact mapping — for longer-term planning fixes

When the workshop surfaces systemic planning problems (e.g., “we don’t align on what ‘done’ means”), impact mapping is a heavier technique for working out why we’re doing any of this. Gojko Adzic’s four levels — Why (goal), Who (actors), How (impacts), What (deliverables) — more work than fits in this workshop, but a strong follow-up if the waste walk shows repeated misalignment between what the team ships and what the business actually wanted.

References

Related guides

• Rework workshop — for tracing rework hours back to their origin in the delivery pipeline.
• Automation workshop — for surfacing manual work that should be automated.
• Strategic event storming — the core exercise technique used in Exercise 3.

Process guide

• SWOT analysis — the framing exercise that opens the workshop.
• 5 Whys — the root-cause chain used in Exercise 5.
• Lightning Decision Jam — the 45-minute substitute when a full 3-hour workshop isn’t available.

Delivery Playbook articles

• My formula for running a successful workshop — the meta-framework this guide follows.
• Solve delivery with a steel thread — answer tough questions first.
• How to use a playbook — guides are scaffolds.
• 2.3 Strategic event storming — the big-picture exercise.
• The 30-minute guide to Domain Driven Design.
• The 30-minute guide to Domain Driven Design — part 2.

External references

• Alberto Brandolini, Introducing EventStorming — the source technique.
• Kurt Lewin, Force Field Analysis (1940s) — see SessionLab for a workshop-ready walkthrough.
• SWOT analysis — classic strategic framework; see TeamRetro SWOT retrospective template for agile adaptations.
• Henri Lipmanowicz and Keith McCandless, Liberating Structures — TRIZ and 1-2-4-All.
• Jonathan Courtney (AJ&Smart), The Lightning Decision Jam: a design exercise that will change your daily life for the better (UX Collective) — the canonical LDJ write-up.
• Gary Klein, Performing a Project Premortem (Harvard Business Review, 2007); see Atlassian’s pre-mortem play.
• Gojko Adzic, Impact Mapping: Making a Big Impact with Software Products and Projects (2012).
• DORA lead time — quantifying the cost of planning latency.
• Jason Fried and DHH, Rework (Basecamp) — “meetings are toxic” chapter for framing.