DAKI Retrospective: Drop, Add, Keep, Improve Guide + Template

The DAKI retrospective (Drop, Add, Keep, Improve) is a process-focused format that drives continuous improvement through four clear action categories. Unlike emotion-centered formats, DAKI cuts straight to what you should change about your workflow, making it ideal for teams focused on optimizing their development process.

This guide shows you how to run an effective DAKI retrospective, with templates and facilitation tips for getting actionable outcomes.

What Is the DAKI Retrospective?

DAKI organizes feedback into four process-improvement categories:

Category	Question	Action Type
Drop	What should we stop doing?	Eliminate
Add	What new things should we try?	Introduce
Keep	What’s working that we should continue?	Maintain
Improve	What existing practices need enhancement?	Optimize

The acronym “DAKI” makes it memorable: Drop, Add, Keep, Improve.

Why DAKI Works

Process-Focused Clarity

DAKI is explicitly about how you work, not how you feel. This makes it:

Efficient for teams comfortable with direct feedback
Easy to convert into backlog items
Clear about expected outcomes

Four Distinct Actions

Each category maps to a specific change type:

Category	Change Type	Example
Drop	Subtract	Remove mandatory daily demos
Add	Create new	Introduce weekly tech talks
Keep	Maintain	Continue pair programming
Improve	Optimize existing	Make standups more focused

Balanced Perspective

DAKI ensures you consider:

Subtractive changes (Drop) — Often overlooked
Additive changes (Add) — New experiments
Status quo (Keep) — What’s working
Incremental improvement (Improve) — Optimization

The Four Categories Explained

Drop: What Should We Stop Doing?

The Drop category identifies practices to eliminate entirely.

What belongs here:

Wasteful activities
Outdated processes
Bureaucratic overhead
Things that don’t add value
Practices causing harm

Examples:

“Drop the weekly status report—no one reads it”
“Drop mandatory attendance at all sprint meetings”
“Drop the manual QA sign-off for minor changes”
“Drop the requirement to update the wiki for every PR”
“Drop the end-of-day Slack check-ins”

Why Drop matters: Teams often add processes but rarely remove them. Drop forces you to consider what to subtract.

Prompts:

What do we do that adds no value?
What would no one miss if it disappeared?
What process exists only because “we’ve always done it”?

Add: What New Things Should We Try?

The Add category captures new practices, tools, or experiments to introduce.

What belongs here:

New process ideas
Tools to evaluate
Practices from other teams
Experiments to run
Missing capabilities

Examples:

“Add feature flags for safer deployments”
“Add a pre-commit hook for linting”
“Add monthly architecture review sessions”
“Add async standup option for remote days”
“Add automated performance testing to CI”

Key distinction: Add is for net new items. If you’re doing something already and want more, that might be “Improve” instead.

Prompts:

What would make our process better?
What have other teams done that we should try?
What tool or practice are we missing?

Keep: What’s Working Well?

The Keep category acknowledges practices that work and should continue unchanged.

What belongs here:

Effective processes
Valuable team practices
Things that would hurt if stopped
Recent improvements that stuck

Examples:

“Keep the morning standup time—it works for everyone”
“Keep code review as a merge requirement”
“Keep the two-week sprint length”
“Keep the retrospective format rotation”
“Keep the team Slack channel for quick questions”

Why Keep matters:

Prevents accidental removal of good practices
Celebrates what’s working
Creates baseline for what not to change

Prompts:

What would we be upset to lose?
What’s working so well we don’t think about it?
What recent changes should we make permanent?

Improve: What Needs Enhancement?

The Improve category identifies existing practices that work but could be better.

What belongs here:

Good processes with friction
Partially effective practices
Things that work but are slow/painful
Opportunities to optimize

Examples:

“Improve code reviews—good but take too long”
“Improve sprint planning—too much time on estimation”
“Improve documentation—useful but often outdated”
“Improve deployment process—works but is manual”
“Improve standups—valuable but sometimes drag on”

How Improve differs from Add:

Add = Something new we’re not doing
Improve = Something we’re doing that needs optimization

How Improve differs from Drop:

Drop = Eliminate entirely
Improve = Keep but make better

Prompts:

What’s good but not great?
What causes friction that we tolerate?
What would we fix with more time?

When to Use DAKI

Situation	Why DAKI Works
Process optimization	Four categories cover all change types
Engineering teams	Technical, process-focused approach
After process experiments	Evaluate what to keep/drop/improve
Quarterly reviews	Good for broader process assessment
Teams comfortable with direct feedback	Less emotional framing

When to Choose Other Formats

Emotional processing needed: Use Mad Sad Glad
Learning-focused: Use 4Ls Retrospective
Visual teams: Try Sailboat
Simpler format: Use Start Stop Continue

How to Run a DAKI Retrospective

Before the Meeting

Preparation:

Schedule 45-60 minutes
Create board with four columns: Drop, Add, Keep, Improve
Review action items from previous retrospective
Consider recent process changes to evaluate

Step-by-Step Facilitation

Step 1: Set the Stage (5 minutes)

Introduce the format:

“Today we’re doing a DAKI retrospective—Drop, Add, Keep, Improve. This format focuses on our processes, not feelings. We’ll look at what to:

Drop — Stop doing entirely

Add — Start doing something new

Keep — Continue as-is

Improve — Make existing things better

Think about our workflow, tools, practices, and collaboration.”

Step 2: Individual Brainstorming (10 minutes)

Have everyone write items silently:

One idea per sticky note
At least 1 item per category
Focus on processes, not people

Facilitator prompts during brainstorming:

“What process adds no value? That’s a Drop.”
“What should we try that we’re not doing? That’s an Add.”
“What’s working perfectly? That’s a Keep.”
“What’s almost great but needs tuning? That’s an Improve.”

💡 RetroFlow has a built-in DAKI template—completely free, no signup required.

Go through each category. Suggested order: Keep → Improve → Drop → Add

This order:

Starts positive (what’s working)
Moves to optimization (improve what exists)
Then elimination (what to drop)
Ends with innovation (new additions)

For each item:

Author explains briefly
Clarify category placement if needed
Group similar items

Category clarification questions:

“Is this really a Drop, or should we Improve it instead?”
“Are we already doing this? If so, is it Add or Improve?”

Step 4: Vote and Prioritize (5 minutes)

Give each person 4-6 votes:

Distribute across categories
Focus on items to act on
Multiple votes on one item allowed

Step 5: Discuss Top Items (15 minutes)

Explore the highest-voted items:

For Drop items:

“What’s blocking us from dropping this?”
“What happens if we just stop tomorrow?”
“Who needs to agree to drop this?”

For Add items:

“How would we experiment with this?”
“What’s the smallest version we can try?”
“What would success look like?”

For Improve items:

“What specifically needs to improve?”
“What would ‘better’ look like?”
“What’s the root cause of the friction?”

For Keep items:

“How do we ensure this continues?”
“Is there risk of losing this?”

Step 6: Create Action Items (5-10 minutes)

Convert discussion into concrete actions:

Category	Item	Action	Owner	Due
Drop	Manual QA sign-off	Update policy doc; announce change	Sarah	Mon
Add	Feature flags	Spike on LaunchDarkly; report findings	Mike	Fri
Improve	Slow code reviews	Implement 24hr SLA; add reviewer rotation	Alex	Next sprint

Step 7: Close (5 minutes)

Summarize action items
Thank participants
Set expectations for follow-up

DAKI Retrospective Template

┌────────────────────────────────────────────────────────────────────────┐
│                         DAKI RETROSPECTIVE                              │
├──────────────────┬──────────────────┬──────────────────┬───────────────┤
│       DROP       │        ADD       │       KEEP       │    IMPROVE    │
│        ✗         │         +        │        ✓         │       ↑       │
│                  │                  │                  │               │
│  What should we  │  What new things │  What's working  │  What needs   │
│  stop doing?     │  should we try?  │  that we should  │  enhancement? │
│                  │                  │  continue?       │               │
│                  │                  │                  │               │
│                  │                  │                  │               │
│                  │                  │                  │               │
│                  │                  │                  │               │
│                  │                  │                  │               │
│                  │                  │                  │               │
└──────────────────┴──────────────────┴──────────────────┴───────────────┘

ACTION ITEMS:
┌────────────────────────────────────────────────────────────────────────┐
│  Action                     │  Owner        │  Due Date                │
├─────────────────────────────┼───────────────┼──────────────────────────┤
│                             │               │                          │
│                             │               │                          │
│                             │               │                          │
└─────────────────────────────┴───────────────┴──────────────────────────┘

Sample Questions for Each Category

Drop Questions

What do we do that no one would miss?
What process exists just because “we’ve always done it”?
What causes frustration without adding value?
What would you eliminate if you could?
What’s bureaucratic overhead we could cut?

Add Questions

What would make our work easier?
What are other teams doing that we should try?
What tool or process are we missing?
What would you add if there were no constraints?
What experiment should we run?

Keep Questions

What’s working so well we take it for granted?
What would we fight to keep if someone tried to remove it?
What recent change should become permanent?
What do we do better than other teams?
What should we protect?

Improve Questions

What’s good but has friction?
What takes too long that shouldn’t?
What’s 80% there but needs polish?
What process do people complain about despite its value?
What would you fix with unlimited time?

For more questions, see our complete retrospective questions guide.

Running this format remotely? Check our guide to remote retrospectives for virtual facilitation tips.

Tips for Facilitating DAKI

Balance the Categories

If one category dominates:

Imbalance	Prompt to Balance
All Drop	”What’s actually working well that we should Keep?”
All Add	”What could we eliminate to make room for new things?”
All Keep	”Is everything really perfect? What could Improve?”
Empty Improve	”What’s good but causes some friction?”

Make Improve Specific

Vague Improve items are hard to act on:

Vague	Specific
”Improve communication"	"Improve standup focus—cap at 15 min"
"Improve code quality"	"Improve test coverage in auth module"
"Improve meetings"	"Improve sprint planning—try async estimation first”

Distinguish Drop vs Improve

Help the team decide:

Drop = Zero value, eliminate entirely
Improve = Has value, but needs optimization

Ask: “If we made this better, would it be worth keeping? If yes, it’s Improve. If no even when improved, it’s Drop.”

For Remote Teams

Use digital collaboration tool
Enable anonymous input for Drop items (can be sensitive)
Give extra time for async brainstorming
Use columns or quadrant layout

DAKI vs Other Formats

Format	Categories	Focus
DAKI	Drop, Add, Keep, Improve	Process optimization
Start Stop Continue	Start, Stop, Continue	Simple action-oriented
Starfish	Keep, Less, More, Stop, Start	Nuanced gradations
4Ls	Liked, Learned, Lacked, Longed For	Emotional + practical

DAKI vs Start Stop Continue

Start Stop Continue	DAKI Equivalent
Start	Add
Stop	Drop
Continue	Keep + Improve

DAKI splits “Continue” into Keep (don’t change) and Improve (optimize), adding nuance.

DAKI vs Starfish

Both have similar categories but different framing:

Starfish uses More/Less gradations
DAKI uses Add/Improve distinction

Choose DAKI for process focus; Starfish for behavioral nuance.

If you like DAKI, try:

Starfish Retrospective — Keep, Less, More, Stop, Start
Start Stop Continue — Simpler three categories
4Ls Retrospective — Adds emotional dimension

For different approaches:

Sailboat — Visual metaphor
Mad Sad Glad — Emotion-focused

See all options in our sprint retrospective formats guide.

Frequently Asked Questions

What does DAKI stand for?

DAKI stands for Drop, Add, Keep, and Improve. Each category represents an action the team can take: Drop what isn’t working, Add new practices, Keep what’s going well, and Improve what could be better.

How is DAKI different from Start Stop Continue?

DAKI adds an “Improve” category that Start Stop Continue lacks. This lets teams discuss things that are working but could be better, rather than just things to start or stop. It produces more nuanced action items.

Is DAKI good for remote teams?

Yes. DAKI works well remotely because the four clear categories are easy to understand without in-person explanation. Use a tool like RetroFlow with a DAKI template and give everyone 10 minutes for silent writing before discussion.

Run This Format Online — Free

RetroFlow includes a DAKI template with everything you need:

Anonymous brainstorming so people speak freely
Dot voting to find what matters most
Action item tracking with owners

No signup required. No cost. Ever.

Launch your retro →

Summary

The DAKI retrospective drives process improvement through four categories:

Drop ✗ — Eliminate what’s not working
Add + — Introduce new practices
Keep ✓ — Maintain what’s working
Improve ↑ — Optimize existing practices

It’s ideal for process-focused teams who want clear, actionable outcomes from their retrospectives.

Sprint Retrospective Formats Guide - 30+ formats
Starfish Retrospective - Similar action-focused format
Creating Effective Action Items - Turn insights into outcomes
Retrospective Anti-Patterns - Common mistakes to avoid

Retrospective Formats Templates Continuous Improvement