The most common retrospective failure: great discussions that lead nowhere. Teams identify problems, have insightful conversations, then nothing changes. The issue? Poor action items—or no action items at all.

This guide shows you how to create action items that actually get done and drive real improvement.

Why Action Items Fail

Common Failure Modes

Too vague:

“Improve communication”

What does that mean? How would you know if you did it?

Too ambitious:

“Rewrite the entire codebase to reduce tech debt”

Impossible to complete in one sprint, gets abandoned.

No owner:

“We should update the documentation”

“We” means no one.

No deadline:

“Eventually migrate to the new API”

Eventually never comes.

Too many:

10 action items from one retrospective

Can’t focus on everything; nothing gets done.

The SMART Framework for Action Items

Good action items are SMART:

Letter	Meaning	Example
S	Specific	”Add unit tests to checkout module”
M	Measurable	”Achieve 80% code coverage”
A	Assignable	”Owner: Sarah”
R	Realistic	Can be done in one sprint
T	Time-bound	”By end of Sprint 15”

Transforming Vague into SMART

Before: “Improve testing” After: “Sarah will add unit tests to the checkout module, targeting 80% coverage, by end of Sprint 15”

Before: “Better communication with Product” After: “Alex will schedule a weekly 30-minute sync with Product starting next Monday”

Before: “Reduce tech debt” After: “Team will dedicate 4 hours this sprint to refactoring the payment service, tracked in Jira”

📖 Explore more: sprint retrospective questions

Action Item Templates

Template 1: Standard Format

[WHO] will [DO WHAT] by [WHEN]

Examples:

• “Jamie will document the deployment process by Friday”
• “Team will try 15-minute standups for the next sprint”
• “Morgan will set up automated testing pipeline by Sprint 16”

Template 2: Experiment Format

We will try [EXPERIMENT] for [DURATION] and measure [SUCCESS METRIC]

Examples:

• “We will try pair programming on complex tasks for 2 sprints and measure defect rate”
• “We will try async standups for 1 week and survey team satisfaction”
• “We will try mob programming for the API integration and compare to solo estimates”

Template 3: Problem-Solution Format

Problem: [ISSUE]
Action: [WHO] will [DO WHAT]
By: [DEADLINE]
Success: [HOW WE'LL KNOW IT WORKED]

Example:

Problem: Requirements change mid-sprint causing rework
Action: Alex will implement change control process with Product
By: Next sprint planning
Success: Changes after day 3 require formal approval

How Many Action Items?

The Golden Rule: 1-3 Per Retrospective

Why limit?

• Focus enables completion
• Quality over quantity
• Builds momentum through visible progress
• Prevents action item debt

What to do with extras:

• Park for future retrospectives
• Note in backlog
• Acknowledge but don’t commit

Prioritization Methods

Dot Voting:

• Each person gets 3 votes
• Vote on most important items
• Top 1-3 become action items

Impact/Effort Matrix:

• High impact, low effort → Do first
• High impact, high effort → Plan carefully
• Low impact, low effort → Maybe do
• Low impact, high effort → Skip

Team Discussion:

• “If we could only fix one thing, what would it be?”
• Consensus on priority

Assigning Owners

Why Ownership Matters

“The team” as owner means no one is responsible. Every action item needs a name.

Owner Responsibilities

The owner doesn’t have to do all the work, but they:

• Ensure the action happens
• Track progress
• Report status at next retro
• Escalate if blocked

Assignment Methods

Volunteer:

“Who would like to own this?”

Works well with engaged teams, can leave some items orphaned.

Round-Robin: Distribute ownership across team members evenly.

Natural Owner: The person closest to the problem or most affected by it.

The Proposer: Whoever raised the issue takes initial ownership.

Tracking Action Items

Method 1: Dedicated Board

Create a simple kanban for retro actions:

┌──────────────┬──────────────┬──────────────┐
│  To Do       │  In Progress │  Done        │
├──────────────┼──────────────┼──────────────┤
│ • Item A     │ • Item C     │ • Item F     │
│   (Sarah)    │   (Alex)     │   (Team)     │
│              │              │              │
│ • Item B     │              │ • Item G     │
│   (Jamie)    │              │   (Morgan)   │
└──────────────┴──────────────┴──────────────┘

Method 2: Sprint Backlog

Add action items as tasks in your sprint backlog:

• Visible alongside regular work
• Competes for sprint capacity
• Clear completion criteria

Method 3: Retrospective Tool

Track in your retrospective tool:

• RetroFlow has action item tracking
• Carry forward incomplete items
• History visible across retros

Method 4: Team Agreement Document

For process changes, add to team working agreements:

• Visible reference
• Discussed at future retrospectives
• Can be revised as team learns

The Retrospective Review Ritual

Start Each Retro with Review

“Before we dive in, let’s review action items from last time.”

For each item:

• Done: Celebrate! Acknowledge the effort.
• In Progress: Brief status update.
• Not Started: Why? What’s blocking? Still relevant?

Questions to Ask

• “Did we complete our action items?”
• “Did the actions have the intended impact?”
• “What did we learn from this experiment?”
• “Should we continue, adjust, or abandon?”

Handling Incomplete Items

If blocked:

• Remove blocker or reassign
• Or acknowledge we can’t do it now

If forgotten:

• Discuss why
• Was it actually important?
• Reprioritize or drop

If still relevant:

• Carry forward with renewed commitment
• Ask what’s different this time

Adapting these questions for a distributed team? Our remote retrospectives guide covers virtual facilitation.

Types of Action Items

Process Changes

“We will start doing daily syncs instead of async updates”

Tips:

• Trial period first
• Clear success criteria
• Revisit at next retro

Task Completion

“Sarah will update the onboarding documentation”

Tips:

• Realistic timeline
• Clear definition of done
• Appropriate priority vs other work

Experiments

“We’ll try mob programming for the complex feature”

Tips:

• Time-boxed trial
• Predefined success metrics
• No-blame if it doesn’t work

Conversations

“Alex will discuss capacity concerns with the Product Owner”

Tips:

• Specific conversation, not vague “improve relationship”
• Concrete ask or topic
• Report back outcome

Decisions to Make

“Team will decide on testing strategy at Thursday’s meeting”

Tips:

• Clear decision point
• Deadline for decision
• Information needed beforehand

Common Action Item Mistakes

Mistake 1: Too Many Items

Problem: 8 action items from one retrospective Fix: Limit to 1-3, prioritize ruthlessly

Mistake 2: No Follow-Through

Problem: Never review previous actions Fix: First 5 minutes of every retro = action review

Mistake 3: Vague Items

Problem: “Improve things” Fix: Use SMART framework, be specific

Mistake 4: Unrealistic Scope

Problem: “Rewrite the entire system” Fix: Break into achievable chunks, start small

Mistake 5: Repeating the Same Items

Problem: “Improve communication” appears every sprint Fix: Ask why it’s not improving, try different approach

Mistake 6: No Owner

Problem: “We should…” or “Someone needs to…” Fix: Every item has a named person

Action Item Examples by Category

Technical

• “Jamie will add monitoring alerts for the payment service by Friday”
• “Team will allocate 4 hours for tech debt this sprint”
• “Morgan will create a deployment checklist by next sprint planning”

Process

• “We’ll try 15-minute standups for 2 weeks, survey satisfaction”
• “Alex will create a PR template to improve code reviews”
• “Team will start sprint planning with capacity discussion”

Communication

• “Sarah will schedule bi-weekly sync with Design team starting Monday”
• “Product Owner will share sprint goals at kickoff (not day 3)”
• “Team will use Slack thread for async questions before meetings”

Team Health

• “We’ll do a team lunch next Friday to celebrate the release”
• “Jamie will send weekly wins summary to boost morale”
• “Team will rotate facilitation to build skills”

Measuring Action Item Success

Track Completion Rate

Sprint 14: 3/3 completed (100%)
Sprint 15: 2/3 completed (67%)
Sprint 16: 3/3 completed (100%)
Average: 89%

Track Impact

Did the action actually help?

Before: “Deploy takes 4 hours” Action: “Automate deployment pipeline” After: “Deploy takes 30 minutes”

Measure the impact, not just the completion.

Signs of Healthy Action Items

• Most items complete within 1-2 sprints
• Same problems don’t keep recurring
• Team feels progress is being made
• Action items come from discussion, not obligation

Frequently Asked Questions

Why do retrospective action items never get done?

Usually because they are too vague, have no owner, or have no deadline. “Improve communication” is a wish, not an action item. “Schedule 15-min sync every Tuesday — owner: Sarah — by next sprint” is actionable.

How many action items should come out of a retrospective?

Aim for 1-3 action items per retrospective. More than that and nothing gets done. It is better to complete one meaningful improvement than to list ten that get forgotten.

Should you review previous action items at the start of each retrospective?

Yes — always. Spending 5 minutes reviewing last retro’s action items builds accountability and shows the team that retrospectives lead to real change. If action items are consistently incomplete, that itself is worth discussing.

Related Resources

• How to Facilitate a Retrospective - Facilitation fundamentals
• Retrospective Anti-Patterns - Common mistakes
• Sprint Retrospective Formats - 30+ formats to try
• Measuring Retrospective Effectiveness - Is it working?

Track Action Items with RetroFlow

RetroFlow helps you create and track effective action items:

• ✅ Action item creation - Capture during retrospective
• ✅ Owner assignment - Clear accountability
• ✅ Export and share - Take actions beyond the board
• ✅ No signup required - Start immediately
• ✅ Completely free - All features included

Start Free Retrospective →