Drop, Add, Keep, Improve: A Simple Retrospective Format

Your retrospectives are too polite to be useful

Most sprint retros are a waste of time.

There, it’s said.

You’ve probably sat in one: 60 minutes of vague “what went well / what didn’t,” a few safe comments about “communication,” everyone nods, someone types notes into Confluence, nothing really changes.

Next sprint: same issues, new sticky notes.

If that sounds familiar, you don’t need more retro “games.” You need a retro format that forces trade-offs and decisions.

That’s where Drop, Add, Keep, Improve (DAKI) comes in. It’s brutally simple, and that’s exactly why it works.

What is Drop, Add, Keep, Improve?

The Drop, Add, Keep, Improve retrospective format asks the team to categorize their ideas into four buckets:

Drop – What should we stop doing entirely?
Add – What should we start doing that we’re not doing now?
Keep – What’s working well and must be preserved?
Improve – What should we continue, but make better?

Unlike the classic “Start / Stop / Continue,” DAKI adds a crucial nuance:

“Improve” forces you to admit that some things are not good enough as-is.
“Keep” forces you to protect what’s working from accidental destruction.

This matters. In many teams, “Continue” becomes a dumping ground for anything that isn’t obviously broken. “Keep” and “Improve” make you think harder.

Why this format actually works in the real world

DAKI works because it:

Forces prioritization – “Drop” makes you confront trade-offs instead of endlessly adding more process.
Surfaces sacred cows – “Keep” makes you explicitly defend things you value, instead of assuming they’ll survive the next reorg.
Encourages incremental change – “Improve” recognizes that most practices aren’t binary good/bad; they evolve.
Is easy to explain – You can teach it in two minutes. No complex facilitation tricks required.

And unlike many retro formats, it scales from a 15-minute hotfix debrief to a 90-minute quarterly retrospective.

How to run a Drop, Add, Keep, Improve retrospective

Here’s a concrete, step-by-step guide you can actually follow.

1. Set a sharp focus (10 minutes)

Most retros fail before they start because the topic is “the sprint.” That’s too broad.

Pick a specific focus:

“How we handled production incidents this sprint”
“Our collaboration with the design team”
“The release pipeline and deployment process”
“Cycle time from ‘Ready for Dev’ to ‘Done’”

Then frame the session with a direct question:

“For this retro, we’re focusing only on how we handled production incidents. What should we Drop, Add, Keep, Improve?”

This constraint makes the conversation concrete and actionable.

2. Silent brainstorming into DAKI buckets (10–15 minutes)

Use four columns or areas labeled:

Drop
Add
Keep
Improve

Give everyone 10–15 minutes of silent writing. No discussion yet.

Examples you might see:

Drop

“Deploying on Friday afternoons”
“Merging PRs with only 1 reviewer”
“Surprise scope changes mid-sprint”

Add

“Dedicated ‘triage’ slot each morning for bugs”
“Slack channel with product + support for quick clarifications”
“Definition of Ready checklist”

Keep

“Daily standup time – works for all time zones”
“Pairing on complex features”
“Our current code review culture (thorough, respectful)”

Improve

“Refinement meetings – too long, too vague”
“Release notes – customers say they’re not clear”
“Story estimates – inconsistent across the team”

Let people write multiple notes per category. Quantity first; you’ll prioritize later.

3. Cluster and clarify (10–15 minutes)

Now, as a group:

Cluster similar notes under each category.
Ask clarifying questions:
- “What exactly do you mean by ‘refinement is chaotic’?”
- “When you say ‘drop Friday deployments,’ what problem are you seeing?”

Do not jump into solutions yet. Your goal here is shared understanding.

Tip: If someone dominates, explicitly rotate:

“Let’s hear from someone who hasn’t spoken yet. Any drops you feel strongly about?”

4. Vote on impact vs. effort (10 minutes)

You will always have more ideas than you can act on. That’s normal.

Use dot-voting or a simple online tool to prioritize:

Give each person 3–5 votes per category.
Ask them to vote for items that:
- Have high impact on team effectiveness or product outcomes.
- Are feasible in the next sprint or two.

You’re not looking for democracy; you’re looking for a signal of what matters most.

5. Turn top items into concrete experiments (15–20 minutes)

Here’s where most retros collapse into vagueness. Don’t let that happen.

For the top 1–2 items per category, define:

Owner – Who will drive this?
Next step – What’s the first concrete action?
When – By when will we do it?
How we’ll know it helped – What metric or signal will we watch?

Example outcomes:

Drop

Item: “Stop merging PRs with only 1 reviewer”
Owner: Tech lead
Action: Update branch protection rules to require 2 approvals
When: Before end of this week
Signal: 100% of merged PRs have 2 approvers

Add

Item: “Add Definition of Ready checklist”
Owner: Product owner
Action: Draft initial checklist, review with team in next refinement
When: Next Tuesday
Signal: All stories in next sprint have DoR checked

Keep

Item: “Keep 9:30am standup”
Owner: Scrum Master
Action: Explicitly document this as a team agreement
When: Today
Signal: Time stays stable through next two sprints unless team votes to change

Improve

Item: “Improve refinement meetings”
Owner: Senior dev + PO
Action: Timebox each story to 8 minutes; use template for acceptance criteria
When: Next refinement
Signal: Number of stories we can refine per session increases by 30%

Write these into your team’s working agreement, Jira board, or wherever your team actually looks.

Real-world examples: DAKI in action

Example 1: The “too many meetings” team

Pain point: Team complained of constant context switching and meeting fatigue.

DAKI outcomes:

Drop:
- Weekly “status sync” that duplicated standup.
Add:
- One consolidated “planning + refinement” block instead of scattered sessions.
Keep:
- 15-minute daily standup, strictly timeboxed.
Improve:
- Sprint review: shift from slide decks to live demos only.

Result after 3 sprints:

Meeting count per dev per week dropped by ~25%.
Lead time for features improved by ~18% (measured via Jira).
Stakeholder satisfaction scores went up because sprint reviews became more concrete and engaging.

Example 2: The “chaotic releases” team

Pain point: Releases kept slipping; hotfixes were common.

DAKI outcomes:

Drop:
- Manual smoke tests done differently by each dev.
Add:
- Simple automated smoke test suite triggered on staging.
Keep:
- Feature flags for risky changes.
Improve:
- Release checklist: standardized, but shortened to focus on critical steps only.

Result after 2 months:

Production incidents per release dropped by ~40%.
Release day overtime went from “normal” to “rare.”

Common mistakes with Drop, Add, Keep, Improve (and how to avoid them)

Mistake 1: Treating it like a suggestion box

If your DAKI board ends up with 30 items and no owners, you’re just doing theater.

Avoid this by:

Limiting outcomes to 3–5 actionable items total per retro.
Refusing to close the session until each has:
- An owner
- A next step
- A date

If everything is important, nothing is.

Mistake 2: Using “Drop” as a venting session

“Drop” is not a place to complain about people; it’s about practices and processes.

Bad:

“Drop: product team changing their mind all the time”

Better:

“Drop: accepting scope changes after sprint planning without renegotiating commitment”

As facilitator, steer the language from blame to behavior.

Mistake 3: Making “Keep” a vanity wall

Teams often treat “Keep” as a feel-good section that nobody ever challenges.

Challenge it:

“We say we want to keep our current review process. Why? What outcome does it protect?”
“If we had to simplify this, what’s the minimum we’d keep?”

If you never move anything from “Keep” to “Improve” over time, you’re not being honest.

Mistake 4: Ignoring data

A retro without data is just opinions fighting.

Before the session, pull simple, relevant metrics:

Lead time / cycle time trends
Bug count per sprint
Deployment frequency
WIP levels
Support tickets volume

Use these to ground your DAKI items:

“We want to keep our current bug triage process. But our bug backlog grew 20% last month. Are we sure?”

Mistake 5: Changing everything at once

DAKI can generate a lot of energy. Don’t let that turn into chaos.

Focus on one significant change at a time per area (process, tools, collaboration).
Use the next retro to assess: did that change help, hurt, or do nothing?

Sustainable improvement beats enthusiastic thrashing.

Practical tips to get the most from DAKI

Make “Drop” non-negotiable

Most teams are addicted to adding more:

More meetings
More checklists
More tools
More reports

But your capacity is finite. If you Add something, you should usually Drop something too.

When an “Add” item wins votes, ask:
- “What will we drop to make space for this?”
Enforce a “no net new process” rule:
- For every new recurring meeting or ritual, something else must go.

This keeps your process lean instead of bloated.

Timebox discussion, not thinking

Timebox:
- Brainstorming (10–15 min)
- Clustering (10–15 min)
- Prioritization (10 min)
- Action planning (15–20 min)
Do not timebox:
- How quickly people must come up with ideas
- Whether people are allowed to add notes late

Some of the best insights come from the quiet person who needs a bit more time.

Use DAKI beyond sprint retros

You can use Drop, Add, Keep, Improve for:

Onboarding retros: “How was your first month here?”
Cross-team collaboration: “How do we work with the data team?”
Incident postmortems: “How we handled outage #1234”
Quarterly planning: “How we run discovery and delivery”

Any recurring activity with a feedback loop can benefit from DAKI.

Make it safer with anonymous input

People won’t put “Drop: our pointless 2-hour stakeholder review” if their manager is in the room and everything is attributed.

Use anonymous input when:

Power dynamics are strong (e.g., senior leaders attending).
Psychological safety is low.
You’re tackling sensitive topics (performance, architecture decisions, etc.).

A lightweight tool with anonymous voting and no signup friction helps you get more honest signals.

Tools that make DAKI easier (without getting in the way)

You don’t need fancy software to run DAKI, but you do need something that:

Supports anonymous input and voting (to reduce anchoring and groupthink).
Integrates with your existing workflow (e.g., Jira) so actions don’t get lost.
Is quick to start; you don’t want to spend 10 minutes on logins.

Tools like ScrumPoi are handy here because they support both planning poker and retrospectives, offer anonymous voting, integrate with Jira, and can be used without signup—useful when you just want to spin up a fast Drop/Add/Keep/Improve session and move on.

Stop admiring the problem. Start making trade-offs.

You don’t need another retro template with cute names.

You need a format that:

Forces you to drop what’s not working.
Lets you add only what you’re willing to invest in.
Protects what you must keep.
Pushes you to improve what’s almost—but not quite—good enough.

Run your next retrospective with Drop, Add, Keep, Improve.

Limit yourself to a handful of concrete changes.

Then, in the next retro, ruthlessly inspect: Did it help? Did it hurt? Do we keep it, improve it, or drop it?

That’s how teams actually get better—one explicit trade-off at a time.