DAKI retrospective: Drop, Add, Keep, Improve

Teams add meetings, tools and rules every quarter and rarely remove any. A DAKI retrospective is the spring clean: decide what to drop, what to add, what to keep as it is and what to keep but fix.

Drop

Practices that no longer earn their keep—what do we discard?

Add

Fresh ideas, tools, or rituals to introduce next cycle

Keep

Behaviors delivering steady value—protect these

Improve

Things worth keeping but polishing—what’s the tweak?

Use this template — it's free

What a DAKI retrospective is

DAKI stands for Drop, Add, Keep, Improve. The team goes through its ways of working — recurring meetings, tools, rituals, rules, documents — and sorts them into four piles: practices that no longer earn their keep, new things to introduce next cycle, things that deliver steady value and should be protected, and things worth keeping that need polishing.

Most retrospectives look at events: what happened this sprint, what went wrong, what went well. DAKI looks at practices, the habits that produce those events. It is closer to an inventory than to a post-mortem, which is why it works best a few times a year rather than every sprint.

What it does that other formats don't:

• It makes removing things legitimate. Most retros end with additions: another check, another meeting, another channel. Over a year the process only grows. The Drop column asks the team what to throw out and gives everyone permission to say it.
• Improve is the honest middle ground. Many practices are neither good nor bad. The standup is useful but too long; the wiki has the right information but nobody finds it. Without an Improve column these end up defended in Keep or attacked in Drop, and the discussion becomes a fight over a yes-or-no answer to a "yes, but" question.
• Every card names something the team controls. A card about a practice can be acted on. That keeps the discussion away from complaints about the weather.

When to use it, and when not to

DAKI pays off when the way the team works has drifted from what the team needs:

• after process bloat — the calendar filled with recurring meetings, the definition of done grew to a dozen items, every change needs three approvals;
• after tooling churn — a move to a new tracker or CI system, three chat channels for the same topic, two places where the documentation might be;
• when the team changes shape — new people, a new manager, two teams merged — and everyone has brought their habits along;
• at the end of a quarter or half-year, as a regular clean-up;
• when the retro itself has become a ritual nobody enjoys; DAKI works on the retro too.

Pick something else when:

• Something just went wrong. After a failed release or a rough sprint, the team wants to understand what went wrong, not audit the calendar. The KPT retrospective works on concrete problems and small experiments.
• The question is how much, not whether. If the practices are right but the dosage is off — too much process here, too little there — Starfish has More of and Less of columns for exactly that.
• The team is brand new. With a few weeks of shared history there is not much to drop yet. A lighter format such as Start Stop Continue is enough.

The four columns

The ProstoRetro board opens with Drop, Add, Keep and Improve. Below is what each column is for, the question that tells it apart from its neighbor, and cards a product team might write.

Drop: what no longer earns its keep

Practices to discard. The test: if we stopped this tomorrow, who would notice, and what would they lose? If the answer is "nobody" or "a little, but it costs more than that", it belongs here. A good Drop card names the practice and the reason, so the discussion is about the trade-off rather than about the person who introduced it.

• The Friday status email: everything in it is already on the board
• Estimating bugs in story points; we never use those numbers
• The #frontend-help channel: nobody answers there, everyone asks in #frontend
• A second approval for pull requests that only change documentation

Add: what to introduce

Fresh ideas, tools or rituals to try in the next cycle. The test: the team does not do this at all today. If you already do it, just badly, the card belongs in Improve. A strong Add card says which problem it solves: "add preview environments" is a tool; "add preview environments so design can review before merge" is a reason.

• An on-call handbook, so a night alert does not depend on who remembers what
• A short demo for support before each release
• Preview environments for every pull request, so design can review before merge
• One afternoon a month for small tech-debt tickets

Keep: what to protect

Behaviors that deliver steady value. The test: it works as it is, and you would argue against anyone who wanted to cancel it. Keep is the column that protects good practices from the next clean-up, a new manager or a reorganization: once the team has said out loud why something works, it is much harder to lose by accident.

• Design review before a ticket enters the sprint
• Rotating the release captain every sprint
• Short decision records for architecture changes
• No meetings before 11:00, so the colleagues three time zones west can join

Improve: what to keep but fix

Things worth keeping that need polishing. The test against Keep: you want it, and you can name what is wrong with it. The test against Drop: losing it would hurt. Ask people to write the tweak on the card, not only the practice; "improve standups" gives the discussion nothing to work with.

• Standup: start with blockers and finish in 15 minutes
• Code review: keep two reviewers, but only for changes to the public API
• Sprint planning: share the candidate tickets a day ahead so people come prepared
• Retros: fewer topics, more time per topic

Use this template — it's free

A 60-minute DAKI agenda

For five to nine people. Prepare one thing in advance: a list of the team's recurring meetings, tools and rules.

1. Warm-up, 5 minutes. A light question from our list of icebreaker questions — the work-related ones lead nicely into talking about habits.
2. Walk through the inventory, 5 minutes. Read the list of meetings, tools and rules out loud, or share it on screen. Without it, people write about the three practices they remember and miss the rest.
3. Silent writing, 10 minutes. One practice per card, in whichever column fits. Nobody sees the other cards until writing ends, so nobody holds back a Drop card because the author of that practice already wrote a Keep.
4. Grouping, 8 minutes. Group cards by practice, even when they sit in different columns. When one person wants to drop the standup and another wants to improve it, that split is often the most useful thing on the board.
5. Voting, 5 minutes. Each person spends their votes on the practices they most want to decide on today.
6. Discussion, 18 minutes. Start with the top Drop topics: they are the hardest and the most valuable. Then the Improve topics, then Add. Keep needs only a minute: read it and agree.
7. Action items, 6 minutes. Each drop needs an owner who tells anyone affected, and a start date. Each add needs an owner and a date to check whether it is working.
8. Close, 3 minutes. Read back what is going and what is coming, and ask how the team feels about the trade.

Drop discussions tend to run long. Setting a meeting length when you create the board lets ProstoRetro divide the time across phases and topics, so the hardest topic cannot eat the whole hour.

Remote facilitation tips

• Build the inventory over a week. A few days ahead, open an infinite room — a permanent board with its own link — and ask people to add a card whenever a practice annoys or helps them. The cards stay hidden until the meeting, and you collect real observations instead of whatever people recall on the call. An infinite room has no meeting length, so time the Drop discussion with the phase timer.
• Let Drop cards be anonymous. Proposing to drop something a colleague introduced is awkward. Cards are anonymous by default; people can still sign the ones they are happy to own.
• Start from suggested groups, then regroup by practice. The app's AI grouping gives you a fast first pass. Then drag cards so each group is about one practice, whatever column its cards came from.
• Poll the close calls. When the team is split between dropping and improving something, put it to an anonymous single-choice poll. You see the real balance before the discussion hardens into two camps.
• Check that dropped things stay dropped. Open action items come back at the start of the next retro. It is the moment to confirm the status email really stopped, and that nobody misses it.

Variations

A narrow DAKI

Point the four columns at one area: only tools, only meetings, only the code review process, only the on-call rotation. A narrow scope gives sharper cards and a shorter session; 30 to 40 minutes is usually enough.

DAKI on the retrospective itself

Once or twice a year, use DAKI to review how the team runs its retros: the formats, the timing, the warm-up, how action items are followed up. Teams rarely question the meeting that is supposed to question everything else.

Five columns with "Not sure"

Some practices are too new to judge. A fifth column for them keeps the four main ones clean, and you look at the "not sure" pile again next quarter. You can build this as a custom template in ProstoRetro, with up to five columns and your own descriptions and colors.

Common mistakes

• An empty Drop column. Politeness wins and nothing gets removed. Use anonymous cards and the "one in, one out" rule to make dropping normal.
• Add as a shopping list. Five new tools, three new rituals, and no capacity to adopt them. Ask which problem each Add solves and cap it at one or two per session.
• Vague Improve cards. "Better planning" cannot be discussed. Every Improve card needs the tweak written on it.
• Dropping without telling anyone. If another team reads your status email, stopping it silently creates a new problem. Each drop needs someone who informs the people affected.
• Running DAKI every sprint. Practices need time to show whether they work. Once a quarter, or after a big change, is the right rhythm.
• Reviewing events instead of practices. "The outage on the 12th" is not a practice. Ask what habit made the outage likely, and put that on the card.

FAQ

What does DAKI stand for?

Drop, Add, Keep, Improve: practices to discard, new ones to introduce, ones to protect, and ones worth keeping that need a tweak.

How is DAKI different from Start Stop Continue?

Drop, Add and Keep map closely to Stop, Start and Continue. The difference is Improve, a separate place for practices you want to keep but change, which Start Stop Continue forces into one of the other columns.

DAKI or Starfish?

Both review practices. DAKI asks whether to keep each one and how to fix it; Starfish asks how much of each you want, with More of and Less of columns. Use DAKI to clean up, Starfish to fine-tune.

How often should a team run a DAKI retrospective?

Once a quarter, or after a big change such as a new tool, a merger of teams or a new manager. Between those, a lighter format keeps retros fresh.

Can I run a DAKI retrospective online for free?

Yes. The DAKI template is built into ProstoRetro and free to use. To build the inventory before the meeting, open an infinite room a week ahead and let people add cards as practices come to mind. Read how to run a great retro for a tour of the app, or see all retrospective templates.