An agile process improvement workshop is a focused session for changing how a team works. It starts with an observed difficulty, examines competing explanations, and ends with a testable change. Its output is not a long wish list; it is a decision the team can act on and review.
This can happen inside a retrospective or as a separate workshop when a problem needs deeper examination. In Scrum, the Scrum Guide gives the Sprint Retrospective a purpose of improving quality and effectiveness. The format below is a suggested facilitation approach, not an additional mandatory Scrum event.
Use the sprint retrospective guide for the broader event. This workshop is narrower: one consequential pattern in the work and one deliberate test.
Choose a problem that the group can influence
Start with an observation rather than a solution. “Reviews wait until Friday” invites investigation. “We need another approval tool” begins with a preferred purchase before the team understands the delay.
Describe the effect on work: waiting, rework, missed feedback, avoidable risk, or an unclear decision. Name the people affected and the period being examined. Avoid using a person's name as the problem statement.
Check decision rights. If the group cannot change the relevant policy or dependency, it may still prepare a recommendation, but that is a different output from an experiment it can authorize itself. Invite the necessary decision owner or state the escalation clearly.
Select a small set of cases. Three well-understood examples can support a useful discussion, but they do not prove how frequently a pattern occurs across all work. Label the limits of the evidence.
Prepare evidence without creating a surveillance exercise
Bring information about the work: handoff dates, queue states, reopened items, decision records, and agreed quality checks. Use appropriate summaries and references rather than copying confidential material into a workshop board.
Ask participants to add context before the meeting. A ticket timestamp may show when a status changed without showing why the team waited. Conversely, a vivid story can be memorable without being representative.
Keep measures at the level needed to test the process. Comparing individuals by activity counts can shift the conversation away from the shared system and encourage defensive explanations. If individual conduct needs attention, use the appropriate separate process.
State what will happen to the notes and who can see them. Participation is easier to interpret when people know whether they are creating a team learning record or an executive report.
A 60-minute workshop agenda
| Time | Activity | Required result |
|---|---|---|
| 0–8 minutes | Agree the problem, boundary, and evidence | One observation-focused problem statement |
| 8–20 minutes | Walk representative cases | Shared account of where work slowed or failed |
| 20–32 minutes | Generate explanations independently, then compare | Plausible causes and unresolved questions |
| 32–45 minutes | Compare small interventions | One selected change with an explicit tradeoff |
| 45–55 minutes | Define the experiment and safeguards | Owner, eligible cases, evidence, and review trigger |
| 55–60 minutes | Check understanding and capacity | Accepted commitment and visible next step |
Do not let the agenda force a premature conclusion. If the evidence is insufficient, commission a bounded investigation with an owner and decision date. “Find out where these cases waited” can be a valid next step; “improve collaboration” is not specific enough.
Invite quieter participants to write before discussion. Ask what would challenge the group's preferred explanation. A majority vote can prioritize a concern, but it cannot establish its cause.
Worked example: reviews accumulate at the end of the week
This hypothetical example uses invented observations and experiment sizes.
A team sees several items waiting for review until Friday. The initial explanation is that reviewers are too busy. Looking at six recent items reveals a more specific pattern: review requests arrive without a clear question or indication of what has changed since the previous version.
That does not prove request quality is the only cause. The team also identifies limited reviewer availability and a late external dependency. It chooses the request-quality hypothesis because it can test it without changing staffing or bypassing review.
For the next eight eligible reviews, the author will include a brief change summary, the decision needed, and any known risk. The reviewer will confirm whether that information is sufficient before beginning the review. Existing quality and approval requirements remain in place.
The team will record time waiting for clarification and inspect two completed review examples. Its guardrail is that the summary should not become a new document requiring more effort than the review itself.
After the eighth case or two weeks, whichever comes first, the team will decide whether to keep, adjust, or stop the practice. Those boundaries make the test reviewable even if the work volume is lower than expected.
Write an experiment card people can actually use
Capture the following in a short shared record:
Observation: What happened in the selected cases?
Hypothesis: Why might this change improve that pattern?
Change: What behavior or process will be different?
Scope: Which cases are included and excluded?
Owner: Who coordinates the test and gathers evidence?
Guardrail: What must not become worse?
Review: Which evidence and date will support a keep, adapt, or stop decision?
Separate the owner of the experiment from the people expected to perform the changed work. Everyone affected needs to understand the request, and external participants must accept their contribution rather than being assigned work after the meeting.
Keep the experiment where normal work is planned. A card left on a workshop board can be easy to forget when delivery pressure returns. Link the learning record to the team's existing task or planning system.
Review learning without overstating the result
At the review, compare what actually happened with what the team expected. Was the change used? Did the relevant waiting pattern change? Did another factor move at the same time? What did participants find burdensome or useful?
A small before-and-after test can support a local decision without proving a universal causal claim. State uncertainty. If the practice seems useful but the evidence is sparse, continue it for a defined period rather than presenting a dramatic productivity gain.
Stop changes that create more cost than benefit. Improvement work competes with other work and should face the same question about value. A workshop is successful when it produces a justified decision, including a decision not to continue an idea.
Use retrospective ideas to vary the reflection format when needed, and the action-items guide to make the next review explicit.
Frequently asked questions
Is this workshop different from a retrospective?
It can be part of one. A retrospective may examine the team's recent work more broadly, while this workshop concentrates on a particular process problem and intervention. Do not add a separate meeting when the existing event can do the job well.
How many improvements should the team select?
Select only as many as the team can implement and evaluate responsibly. Starting with one meaningful change often makes the evidence easier to interpret. A fixed quota matters less than available capacity and clear ownership.
What if the cause is outside the team's control?
Prepare a specific request or recommendation for the responsible owner, including evidence and the decision needed. Avoid promising an experiment the team cannot authorize. Where possible, choose a local mitigation while the broader decision is pending.