Sprint Retrospective Format for Deciding What to Do: Prioritizing Action Items
This skill teaches you how to help your team select, prioritize, and commit to specific, actionable improvements from a retrospective so they actually get implemented in the next sprint.
To prioritize retrospective action items, first dot-vote on candidate improvements to surface team priorities. Then filter for items within the team's control and small enough to complete in one sprint. Limit commitment to 1–3 actions, assign a clear owner to each, and define specific acceptance criteria. This sprint retrospective format ensures teams commit to changes they'll actually implement rather than generating wish lists.
Outcome: Your team consistently leaves retrospectives with 1–3 clearly owned, realistically scoped action items that get completed before the next retro.
Prerequisites
- Familiarity with basic agile retrospective structure
- Experience gathering data and generating insights in retrospectives
- Understanding of team capacity and sprint planning
Overview
"Decide What to Do" is the fourth phase of the Five-Step Retrospective Framework, and it's arguably where most retrospectives succeed or fail. After you've set the stage, gathered data, and generated insights, the team is sitting on a rich set of potential improvements. The challenge is converting that list into a small number of commitments the team will actually follow through on.
Many teams skip rigorous prioritization and end up with vague resolutions like "communicate better" or ambitious lists of ten improvements that never happen. A well-designed sprint retrospective format for this phase uses structured voting, feasibility filtering, and explicit commitment rituals to ensure the team walks out with actions that stick. The goal isn't to fix everything — it's to fix one or two things completely before the next retrospective.
This skill covers the practical facilitation techniques, voting methods, and commitment patterns that transform retrospective outputs from wish lists into tangible team improvements. When done well, this phase creates a virtuous cycle: the team sees real change, which builds trust in the retrospective process, which increases engagement in future retrospectives.
How It Works
The "Decide What to Do" phase works by applying progressive filtering to narrow a broad set of potential improvements down to a committed few. Think of it as a funnel with three stages: surface preferences (voting), test feasibility (filtering), and lock in commitment (ownership and specificity).
First, the team uses a democratic mechanism — most commonly dot voting — to signal which insights or improvement ideas they believe will have the highest impact. This prevents the loudest voice or the most senior person from dictating the agenda. The voting surface reveals where collective energy already exists, which is a leading indicator of follow-through.
Next, the top-voted items pass through a feasibility filter. The facilitator guides the team to ask: Can we actually do this in one sprint? Is this within our control? Can we define what 'done' looks like? Items that fail these tests get reformulated or deferred — not discarded, but placed in a parking lot for future retrospectives or escalated to management if they require organizational change.
Finally, each surviving action item gets sharpened into a SMART-style commitment: specific behavior or deliverable, a single owner (not "the team"), and clear acceptance criteria. The facilitator explicitly asks for verbal commitment. This ritual matters because psychological research on implementation intentions shows that specificity and public commitment dramatically increase follow-through rates. The output feeds directly into sprint planning and into your action item tracking system.
Step-by-Step
Step 1: Consolidate and Cluster Improvement Ideas
Before voting, review the insights and improvement ideas generated in the previous phase. Group duplicates and closely related items together using affinity mapping. Read each cluster aloud and give it a short label so the team shares a common understanding of what each option actually means.
This step prevents vote-splitting, where three similar ideas each get a few votes instead of one consolidated idea getting strong support. It also surfaces hidden connections — two seemingly different suggestions might actually be addressing the same root cause.
Aim for 5–10 distinct clusters. If you have more, the team may need to do a quick pre-filter to remove items that are clearly out of scope or already in progress.
Tip: Write cluster labels as verb phrases ('Add integration tests to deploy pipeline') rather than nouns ('Testing') to keep the team thinking in terms of concrete actions.
Step 2: Dot Vote to Surface Team Priorities
Give each team member a fixed number of votes — typically 3–5 dots for a list of 5–10 items. Team members place their dots on the items they believe will have the most positive impact on the team's performance. Allow stacking (multiple dots on one item) so people can express strong preferences.
Collect votes simultaneously to avoid anchoring bias. In physical settings, have everyone walk up at once. In virtual settings, use a tool with hidden voting that reveals results after everyone has voted.
Once votes are revealed, rank the items by vote count. Identify the top 3–5 items as candidates for commitment. If there's a clear gap between a cluster of high-vote items and the rest, the prioritization is straightforward. If votes are evenly distributed, you may need a brief discussion or a second round of voting on just the top candidates.
Tip: If your team has fewer than 5 people, give each person only 2–3 votes to create meaningful differentiation. Too many votes per person flattens the results.
Step 3: Apply the Feasibility Filter
Take each top-voted candidate and run it through three questions with the team:
- Is it within our control? If the action requires approval from another department, budget allocation, or organizational policy changes, it's not a good sprint-level action item. Flag it for escalation instead.
- Can we complete it in one sprint? If the answer is 'probably not,' break it down. What's the smallest slice that would still be meaningful?
- Can we define 'done'? If the team can't articulate what success looks like, the item isn't specific enough yet.
Items that fail the filter aren't thrown away. Move them to a 'parking lot' visible to the team, or convert them into escalation items the Scrum Master or manager will carry forward. This validates the team's concern while keeping the action list realistic.
Tip: Keep this step brisk — spend no more than 2 minutes per item. The goal is a quick gut check, not a detailed planning session.
Step 4: Sharpen Actions into SMART Commitments
For each item that passes the feasibility filter, collaboratively rewrite it as a specific commitment. A well-formed retrospective action item has four elements:
- What specifically will change (a behavior, a process step, a tool configuration)
- Who owns it (a single person, not 'the team')
- When it will be done (by end of next sprint, by next Wednesday, etc.)
- How we'll know it's done (observable outcome or artifact)
For example, 'improve code reviews' becomes 'Jamie will create a code review checklist by Wednesday and the team will use it for all PRs in Sprint 14. Done means the checklist exists in Confluence and has been used on at least 3 PRs.'
This transformation is where the real value happens. Vague intentions become trackable commitments.
Tip: Ask the owner to rephrase the commitment in their own words. If they can't, it's a sign the action isn't clear enough yet.
Step 5: Limit to 1–3 Actions Maximum
Even if multiple items passed the feasibility filter, resist the temptation to commit to all of them. Research on behavior change and team performance consistently shows that fewer commitments lead to higher completion rates.
If the team has 4–5 strong candidates after filtering, facilitate a brief final round of discussion: 'If we could only do one of these, which would it be?' Then ask, 'Can we realistically do a second?' Most teams should commit to 1–2 actions in a two-week sprint. Three is the hard ceiling for experienced teams with a strong track record of completing retro actions.
The remaining items go into the parking lot for the next retrospective. They won't be forgotten if you're tracking action items across sprints.
Tip: A team that consistently completes 1 action item per sprint will make 26 concrete improvements per year. That compounds dramatically.
Step 6: Secure Explicit Verbal Commitment
Before moving to closing the retrospective, read each action item aloud — including the owner, the deadline, and the done criteria. Ask the owner directly: 'Are you committed to this?' Then ask the team: 'Are we all committed to supporting this?'
This isn't a formality. Public verbal commitment activates consistency bias — people are significantly more likely to follow through on promises made in front of peers. It also surfaces last-minute objections ('Actually, I'm on vacation next week, can someone else own this?') before they become missed commitments.
Document the commitments in a visible, shared location immediately — on the team board, in Jira, in your retrospective tracking tool. Don't wait until after the meeting.
Tip: Take a photo of the physical board or screenshot the virtual board before anyone leaves. Retrospective outputs have a way of evaporating if not captured in the moment.
Examples
Example: A Backend Team Prioritizes After a Painful Deploy
A backend team of 6 has just completed the 'Generate Insights' phase and has 8 improvement ideas on the board, ranging from 'automate database migration scripts' to 'pair program more often' to 'get the PM to write clearer acceptance criteria.' The facilitator has 15 minutes to guide the team through deciding what to do.
The facilitator first clusters the 8 items, finding that 'automate DB migrations' and 'add rollback scripts' are related — she groups them under 'Deploy Safety.' This leaves 7 distinct clusters.
She gives each person 3 dot votes. Results: 'Deploy Safety' (9 dots), 'Clearer acceptance criteria' (5 dots), 'Pair programming' (4 dots), everything else (0–2 dots).
She takes the top 3 through the feasibility filter:
- Deploy Safety: Within control? Yes. One sprint? The full automation isn't, but 'write rollback scripts for the 3 most critical migrations' is. Definable done? Yes — scripts exist and have been tested.
- Clearer acceptance criteria: Within control? Partially — it requires PM behavior change. The team reframes it as 'Create an AC template and propose it to the PM by Wednesday.'
- Pair programming: Within control? Yes. But the team realizes they can only realistically commit to 2 items this sprint.
Final commitments:
- 'Marcus will write rollback scripts for the auth, billing, and user migrations by end of Sprint 12. Done = scripts in repo and dry-run tested in staging.'
- 'Priya will draft an acceptance criteria template by Wednesday and schedule a 15-minute review with the PM. Done = template shared and PM feedback received.'
Pair programming goes to the parking lot. Both owners verbally confirm. The facilitator screenshots the board and posts it to the team Slack channel.
Example: A Cross-Functional Team Uses the Sprint Retrospective Format with Effort/Impact Matrix
A cross-functional product team is struggling with retrospective follow-through. They've been averaging 5–6 action items per retro and completing only 1. The Scrum Master decides to change the sprint retrospective format for the 'Decide What to Do' phase.
Instead of simple dot voting, the Scrum Master introduces a 2x2 effort/impact matrix. After the team generates 6 improvement ideas, she draws a grid on the whiteboard: high impact / low effort (top-left), high impact / high effort (top-right), low impact / low effort (bottom-left), low impact / high effort (bottom-right).
The team collaboratively places each item on the grid. Two items land in the 'high impact, low effort' quadrant: 'Add a PR description template to GitHub' and 'Move standup from 9am to 9:30am.' One item — 'Refactor the notification service' — lands in high impact but also high effort.
The Scrum Master proposes committing only to the two quick wins this sprint. The team agrees. For the refactor, they create a spike story: 'Anika will spend 2 hours documenting the current notification service architecture and identifying the smallest valuable refactor. Done = document in Confluence by Friday.'
This sprint retrospective format shift results in 3/3 action items completed — the team's first 100% completion rate in months. The visible success builds momentum for the next retro.
Best Practices
Always review the status of previous retrospective action items before deciding on new ones. Unfinished items either need to be recommitted to or explicitly dropped — carrying invisible debt undermines trust in the process.
Use a 'circle of control' visual to help the team distinguish between actions they can take independently, actions that need collaboration with other teams, and systemic issues that require management escalation. Only commit to items in the inner circle.
Add retrospective action items directly to the next sprint backlog during sprint planning — don't treat them as side work. If improvement work doesn't get the same visibility as feature work, it won't get done.
Rotate the owner role for action items across sprints so the same 1–2 motivated people don't end up carrying all improvement work. This distributes learning and prevents burnout.
When an action item is too large, use the 'experiment' framing: 'Let's try X for one sprint and evaluate.' This lowers the commitment threshold and makes it psychologically safer to propose bold changes.
Keep a visible 'done' wall or channel where completed retrospective actions are celebrated. Acknowledging progress reinforces the behavior of following through.
Common Mistakes
Committing to too many action items (5+ per sprint)
Correction
Limit to 1–3 actions maximum. Completing one meaningful improvement is worth far more than partially attempting five. Track your completion rate — if it drops below 80%, you're overcommitting.
Writing vague action items like 'communicate better' or 'improve quality'
Correction
Apply the specificity test: can a new team member read this action item and know exactly what to do? Rewrite until the answer is yes. 'Communicate better' becomes 'Post daily async standup updates in Slack #team-updates by 10am, starting Monday.'
Assigning action items to 'the team' instead of a specific owner
Correction
Every action needs exactly one owner. 'The team' means nobody. The owner doesn't have to do all the work — they're responsible for making sure it gets done and reporting back.
Letting the highest-paid person's opinion (HiPPO) override the team vote
Correction
Use anonymous or simultaneous voting to neutralize authority bias. If a manager or tech lead wants to override the vote, they should make their case and let the team re-vote rather than simply overruling.
Never revisiting the parking lot of deferred items
Correction
Start each retrospective's 'Decide What to Do' phase by reviewing the parking lot. Items that keep reappearing are either genuinely important (and need to be prioritized) or no longer relevant (and should be removed).
Other Skills in This Method
Closing Retrospectives Effectively
How to wrap up a retrospective by summarizing decisions, appreciating contributions, and gathering feedback on the retro process itself.
Choosing Retrospective Activities and Exercises
How to select and facilitate engaging activities like Sailboat, Mad/Sad/Glad, or Timeline for each phase of the five-step retrospective.
Building Sprint Retrospective Templates
How to design reusable retrospective templates that map activities to each of the five phases for consistent and efficient facilitation.
Tracking Retrospective Action Items Across Sprints
Practices for following up on retrospective commitments, measuring improvement progress, and ensuring accountability between sprint cycles.
Setting the Stage for Effective Retrospectives
How to open a retrospective by establishing a welcoming environment, setting the tone, and defining the session's focus and working agreements.
Generating Insights from Retrospective Data
How to facilitate analysis of gathered data to uncover root causes, patterns, and meaningful insights that go beyond surface-level observations.
Gathering Data During Sprint Retrospectives
Techniques for collecting objective facts, events, metrics, and team sentiments from the past iteration to create a shared understanding of what happened.
Related Skills from Other Methods
Frequently Asked Questions
How many action items should a team commit to per sprint retrospective?
Commit to 1–3 action items maximum. Research and practitioner experience consistently show that teams completing fewer items per sprint make more cumulative progress than teams that overcommit. If your completion rate is below 80%, reduce the number until follow-through becomes reliable.
What sprint retrospective format works best for prioritizing action items?
Dot voting is the most common and effective sprint retrospective format for prioritization because it's fast, democratic, and easy to facilitate. For teams that need more nuance, an effort/impact matrix helps distinguish quick wins from larger investments. Both approaches are part of the 'Decide What to Do' phase in the Five-Step Retrospective Framework.
What should I do with retrospective ideas that don't get selected?
Place unselected items in a visible parking lot and review them at the start of the next retrospective's prioritization phase. Items that recur across multiple retros are signaling a persistent problem that deserves attention. Items that lose relevance over time can be archived.
How do I make sure retrospective action items actually get completed?
Three practices drive completion: assign a single owner (not 'the team'), add the item to the sprint backlog so it's visible during daily standups, and review completion status at the start of the next retrospective. See our guide on tracking retrospective action items across sprints for a complete system.
Should retrospective action items be added to the sprint backlog?
Yes. Action items that live only in retrospective notes tend to be forgotten. Adding them to the sprint backlog gives them visibility, allows the team to account for the effort during planning, and creates accountability through daily standups and sprint reviews.
How do I handle action items that are outside the team's control?
Separate these from team-level commitments. Reframe what the team *can* do — often this means 'escalate with data.' For example, 'We need faster CI servers' becomes 'Tech lead will present CI wait-time data to engineering management by Thursday and request a budget review.' The team owns the escalation, not the outcome.