Keep Drop Try Retrospective: Simple Format for Continuous Improvement

The Keep Drop Try retrospective is a straightforward format that focuses on three clear actions: keeping what works, dropping what doesn’t, and trying new experiments. Its simplicity makes it perfect for teams who want actionable outcomes without complex facilitation.

If your team is tired of retrospectives that generate discussion but not action, Keep Drop Try cuts straight to what matters: decisions about your practices.

What Is the Keep Drop Try Retrospective?

The Keep Drop Try retrospective organizes feedback into three action-oriented categories:

Category	Symbol	Focus
Keep ✅	Continue	What’s working—maintain these practices
Drop 🗑️	Stop	What’s not working—eliminate these
Try 🧪	Experiment	New ideas to test next sprint

Each category leads directly to a clear action, making follow-through straightforward.

Why the Keep Drop Try Format Works

Action-Oriented Design

Every item maps to a specific action:

Keep → Continue doing
Drop → Stop doing
Try → Start experimenting

No ambiguity about what happens next.

Encourages Experimentation

The “Try” category is particularly powerful:

Creates space for innovation
Reduces risk by framing as experiment
Builds culture of continuous improvement
Makes it safe to propose new ideas

Simple and Fast

The format is:

Easy to explain in 30 seconds
Quick to set up
Intuitive for team members
Completable in 30 minutes

Balanced Perspective

The three categories ensure:

Positive recognition (Keep)
Problem identification (Drop)
Forward progress (Try)

The Keep Drop Try Categories Explained

Keep ✅ — What’s Working

The Keep category identifies practices the team should continue.

What belongs here:

Effective processes
Helpful tools
Good team habits
Successful practices from experiments
Things that contribute to success

Examples:

“Keep: Morning standup at 9:15 AM”
“Keep: Pair programming on complex features”
“Keep: Friday code review cleanup sessions”
“Keep: Sprint backlog visible on the wall”
“Keep: Celebrating wins at end of sprint”

Criteria for Keep:

Has proven value over time
Team agrees it should continue
Would be missed if stopped

Prompts:

What should we definitely continue?
What would hurt us if we stopped?
What practices are working well?

Drop 🗑️ — What’s Not Working

The Drop category identifies practices to eliminate.

What belongs here:

Wasteful activities
Frustrating processes
Counterproductive habits
Failed experiments
Things adding friction

Examples:

“Drop: Mandatory 1-hour status meetings”
“Drop: Individual task assignments—use team pull instead”
“Drop: Updating three different tracking systems”
“Drop: Afternoon deployments on Fridays”
“Drop: Waiting for full feature before any testing”

Criteria for Drop:

Clearly not working
Team agrees to stop
Won’t create new problems if eliminated

Prompts:

What should we stop doing immediately?
What’s wasting our time?
What practice isn’t delivering value?

Try 🧪 — New Experiments

The Try category proposes new practices to test.

What belongs here:

New process ideas
Suggested improvements
Practices borrowed from other teams
Solutions to current problems
Innovation proposals

Examples:

“Try: Mob programming for one feature”
“Try: 15-minute time-box for standups”
“Try: Async written standups on Mondays”
“Try: Pair rotation every two days”
“Try: No-meeting Wednesday afternoons”

Criteria for Try:

Clearly defined experiment
Feasible to implement next sprint
Has measurable success criteria
Team willing to commit

Prompts:

What should we experiment with?
What might improve our work?
What have we been curious to try?

When to Use Keep Drop Try

Situation	Why Keep Drop Try Works
Teams wanting action	Every item leads to clear decision
Fast retrospectives	Completable in 30 minutes
New teams	Simple format easy to learn
Routine sprints	Good for regular cadence
Teams with experiment culture	”Try” category fits naturally
Action item follow-up	Clear tracking of decisions

When to Choose Other Formats

Need emotional processing: Use Mad Sad Glad
Want nuanced feedback: Use WWW or 4Ls
Visual engagement: Use Sailboat or Hot Air Balloon
Comprehensive review: Use 360 Degree

How to Run a Keep Drop Try Retrospective

Before the Meeting

Preparation:

Schedule 30-45 minutes
Prepare board with three columns
Review previous “Try” items for follow-up
Check status of previous “Drop” and “Keep” decisions

Step-by-Step Facilitation

Step 1: Set the Stage (3 minutes)

Introduce the format:

“Today we’re using Keep Drop Try. We’ll identify:

✅ Keep — Practices that work—we’ll continue these

🗑️ Drop — Things not working—we’ll stop these

🧪 Try — New experiments for next sprint

Everything we add should lead to a clear action.”

Reference previous experiments: “Let’s also check in on last sprint’s ‘Try’ items—did they work?”

Step 2: Review Previous Experiments (5 minutes)

Before generating new items, review previous “Try” experiments:

Last Sprint’s “Try”	Result	New Status
15-min standup time-box	Worked well	→ Move to Keep
Async Monday standups	Mixed results	→ Try again with adjustment
No-meeting afternoons	Didn’t work	→ Drop or modify

This creates accountability and shows experiments have consequences.

Step 3: Silent Brainstorming (7 minutes)

Have team members add items to each column:

One idea per sticky note
Be specific about what to Keep, Drop, or Try
For “Try” items, include brief description of the experiment

Facilitator tip: Encourage at least one item per person in each category.

💡 RetroFlow tracks experiments across sprints—free, no signup required.

Go through each column:

Recommended order:

Keep — Celebrate what’s working
Drop — Address what’s not
Try — Explore new ideas

For each item:

Brief explanation from author
Quick team alignment check
Cluster similar items

Discussion focus:

Keep: “Everyone agree this should continue?”
Drop: “Are we ready to stop this?”
Try: “Is this a clear experiment we can run?”

Step 5: Commit to Actions (10 minutes)

Turn items into commitments:

Keep commitments:

Document in team agreements
Ensure practices are shared with new members
Celebrate success

Drop commitments:

Specific date to stop
Communication plan if others affected
Alternative if needed

Try commitments:

Clear experiment definition
Success criteria
Duration (usually one sprint)
Who’s responsible for tracking

Example experiment definition:

Try: Mob programming sessions
What: Whole team works on one feature together
When: Tuesday and Thursday afternoons
Duration: Next sprint
Success criteria: Team reports it helpful, feature quality improves
Review: Next retrospective

Step 6: Close (5 minutes)

Confirm all three categories have commitments
Document experiments for next retrospective
Thank the team

Keep Drop Try Template

┌──────────────────────────────────────────────────────────────────────┐
│                     KEEP DROP TRY RETROSPECTIVE                       │
├────────────────────┬────────────────────┬────────────────────────────┤
│   ✅ KEEP          │   🗑️ DROP          │      🧪 TRY                │
│                    │                    │                            │
│   Continue doing   │   Stop doing       │      Experiment with       │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
│                    │                    │                            │
└────────────────────┴────────────────────┴────────────────────────────┘

Previous Experiments Review:
┌─────────────────────────────────────────────────────────────────────┐
│ Experiment              │ Result          │ New Status              │
├─────────────────────────┼─────────────────┼─────────────────────────┤
│                         │ ✅ / 🟡 / ❌    │ Keep / Drop / Adjust    │
│                         │                 │                         │
└─────────────────────────┴─────────────────┴─────────────────────────┘

Sample Items for Each Category

Keep Examples

Daily standups format
Code review before merge
Sprint planning sessions
Slack channel for quick questions
Friday demos to stakeholders
Definition of Done checklist

Drop Examples

Mandatory status update emails
Estimation in hours
Long-lived feature branches
All-hands meetings for status
Individual task assignment
Synchronous approval workflows

Try Examples

Pair programming Tuesdays
Written async standups
Two-day story time-box
Trunk-based development
No-meeting mornings
Rotating facilitator role

For discussion prompts that pair well with this format, see our retrospective questions guide.

Tips for Facilitating Keep Drop Try

Make “Try” Experiments Clear

Vague experiments fail. Ensure each “Try” item has:

What: Specific practice to try
When: Time or trigger
How long: Duration of experiment
Success criteria: How to evaluate
Review: When to assess results

Track Experiments Across Sprints

Create an experiment log:

Sprint	Try Item	Status	Outcome
S1	Mob programming	Completed	→ Keep
S1	Async standups	Completed	→ Drop
S2	15-min time-box	In progress	Review S3

Balance the Categories

Watch for imbalances:

Heavy Keep, light Drop:

Team might be avoiding hard conversations
Prompt: “What would make our work easier if we stopped?”

Heavy Drop, light Keep:

Team might be too negative
Prompt: “What got us through this sprint?”

Light Try:

Team might be in maintenance mode
Prompt: “What have we been curious about?”

Limit Experiments

Don’t overload with “Try” items:

Max 2-3 experiments per sprint
Running too many makes evaluation difficult
Better to deeply test few than superficially test many

Variations on Keep Drop Try

Keep Drop Try + Improve

Add fourth column for existing practices that need adjustment:

Keep	Improve	Drop	Try
Continue as-is	Adjust existing	Stop	New experiment

Keep Drop Try with Timeboxing

Structure experiments with clear end dates:

Try for 1 sprint — Quick experiments
Try for 2 sprints — Longer evaluation
Try permanently — Ready to commit

Team Agreement Integration

Use results to update team agreements:

Team Agreements (Updated Sprint 5):
- Daily standup at 9:15 AM [Keep since S1]
- Code reviews within 24 hours [Keep since S3]
- No Friday deployments [Keep since S4]
- Mob programming Tuesdays [Try, reviewing S6]

Common Mistakes to Avoid

Mistake 1: Vague Experiments

Problem: “Try: Better communication” Fix: “Try: 5-minute check-in at start of each pairing session”

Mistake 2: Not Reviewing Previous Experiments

Problem: “Try” items are forgotten next sprint Fix: Start each retrospective by reviewing previous experiments

Mistake 3: Too Many Experiments

Problem: Five new things to try overwhelms the team Fix: Limit to 2-3 experiments per sprint maximum

Mistake 4: No Success Criteria

Problem: Can’t tell if experiment worked Fix: Define measurable criteria: “Standups under 15 minutes 80% of time”

Mistake 5: Dropping Without Alternative

Problem: Stopping practice creates vacuum Fix: If dropping addresses a need, propose alternative in “Try”

Experiment Tracking Template

Track experiments over multiple sprints:

┌────────────────────────────────────────────────────────────────────┐
│                    EXPERIMENT TRACKER                               │
├──────────────┬──────────────┬──────────────┬──────────────────────┤
│ Experiment   │ Started      │ Status       │ Outcome              │
├──────────────┼──────────────┼──────────────┼──────────────────────┤
│ Mob coding   │ Sprint 3     │ Completed    │ → Keep (Tue/Thu)     │
│ Async stand  │ Sprint 3     │ Completed    │ → Drop (low engage)  │
│ 15-min time  │ Sprint 4     │ Running      │ Review Sprint 5      │
│ No-mtg Wed   │ Sprint 5     │ New          │ Review Sprint 6      │
└──────────────┴──────────────┴──────────────┴──────────────────────┘

If your team likes Keep Drop Try, also try:

Start Stop Continue — Similar simplicity, less experiment focus
DAKI — Drop, Add, Keep, Improve
Starfish — Five actions including “More of” and “Less of”
WWW — Worked Well, Kinda Worked, Didn’t Work

See all options in our sprint retrospective formats guide.

Give It a Try

Want to run a Keep Drop Try retrospective without fussing over setup? RetroFlow comes with a built-in template, dot voting, and anonymous mode — no signup, no cost.

Start a free retro →

Summary

The Keep Drop Try retrospective organizes feedback into three action-oriented categories:

✅ Keep — Continue practices that work
🗑️ Drop — Stop things that don’t work
🧪 Try — Experiment with new ideas

Its strength is clarity: every item leads to a specific action. The “Try” category encourages experimentation by framing new ideas as time-boxed tests rather than permanent commitments.

Run it in 30-45 minutes with emphasis on tracking experiments across sprints for maximum value.

Sprint Retrospective Formats Guide - 30+ formats
Start Stop Continue Retrospective - Similar simplicity
Creating Effective Action Items - Better follow-through
How to Facilitate a Retrospective - Facilitation tips

Retrospective Formats Templates Continuous Improvement