DAKI
No remaining value — a report nobody reads, a step already automated
Roman
Maria
A new practice to try, one or two per sprint
Anna
Daria
Works today and should be defended under pressure
Maria
Kirill
Nearly right — needs fixing rather than removing
Daria
Roman
What is DAKI?
DAKI stands for Drop, Add, Keep, Improve. It is a retrospective format in which every card is a proposal about how the team works: something to remove, something to introduce, something to protect, or something to make better. There is no column for observations, feelings or events — the board contains decisions in draft form and nothing else.
That constraint is what makes DAKI fast. In a format organised around what went well and badly, roughly half the session is spent converting observations into proposals; DAKI asks people to do that conversion while they are writing. The trade-off is that it only works when the team already understands what happened. Given a confusing sprint, DAKI produces confident proposals aimed at the wrong problem.
When to use DAKI
- For a routine sprint retrospective in a team that already talks openly about its problems.
- When previous retrospectives produced discussion but no change — every card here is already shaped like an action.
- When the session is short: 40 minutes is enough because no time goes into translating observations into proposals.
- A few weeks after a process or tool change, to tune it rather than reopen the decision.
- When process weight is the issue — the Drop column gives people explicit permission to propose removing things.
- For a team new to retrospectives that wants immediate results, since the connection between the board and next week's behaviour is obvious.
It is the wrong choice after an incident, a failed release or a sprint nobody can explain. Diagnose first with a format built for discovery, then run DAKI in the following session to decide what to do.
The columns explained
Drop
Practices, artefacts and habits with no remaining value: a report nobody reads, a ceremony that duplicates another, a manual step automated months ago, an approval that has never once resulted in a rejection. Drop is the column teams underuse, because removing something feels riskier than adding something. It is usually where the cheapest wins are.
Add
Practices the team does not have and wants to try. Limit this to one or two per sprint. New habits compete for the same attention, and a team that adds four at once keeps none of them — which then teaches everyone that retrospective outcomes are optional.
Keep
Things that work and should be protected. Not a compliments round: a Keep card is a commitment to defend a specific practice when the next deadline arrives. The practices a team loses first under pressure are the ones nobody named as valuable.
Improve
Things that exist but do not work well enough. Standup that runs too long, a test suite that is slow rather than wrong, documentation that exists but is out of date, a review process that is sound but too slow. This is the column that separates DAKI from a simple keep-or-drop format, and cards here need the most specific wording — "improve our documentation" is not an action, "add a runbook link to every alert" is.
Example board
A six-person team ran DAKI after a sprint that delivered on time but felt heavier than it should have.
| Drop | Add | Keep | Improve |
|---|---|---|---|
| The weekly status email — the same information is on the board | A linter in the pipeline so formatting never reaches review | Support rotation; nobody is permanently on call | Standup — twenty-five minutes for six people, and half of it is status |
| Two alert channels nobody acts on | A written handover when someone is pulled off the sprint | Writing a failing test before fixing a bug | Review latency — the large pull requests sit for days while the small ones go same day |
| Keeping tickets open purely to signal status | Friday demo — the only time the whole team sees the product | Onboarding docs — they exist but describe a service we replaced |
Voting put the standup card and the review latency card at the top. Standup was capped at ten minutes with status moved to the board, which was done the next morning. Review latency turned into a size limit rather than a speed commitment: pull requests over 300 lines get split, on the evidence that small ones were already being reviewed the same day. The linter was added the same afternoon and removed an entire class of review comment.
Timing for a team of 5–10
| Step | Time | What happens |
|---|---|---|
| Review last time's actions | 4 min | Read out the previous items and mark honestly what was done. |
| Write in silence | 8 min | All four columns at once, cards hidden until the timer ends. |
| Read and group | 8 min | Reveal, read every card aloud, merge duplicates. |
| Vote | 3 min | Three votes per person across the whole board. |
| Decide | 15 min | Work down the ranking. For each item, state what changes on Monday. |
| Close | 5 min | Owners and dates. Three items maximum. |
Facilitator prompts
- Drop: "What do we produce that nobody reads?" — "Which meeting would you skip if you could, and what would actually break?"
- Add: "What did you wish we had when something went wrong this sprint?"
- Keep: "What would you protect if next month got busy?"
- Improve: "What is nearly right?" — "What do we do properly but too slowly?" — "What exists but is out of date?"
- On any card: "What does that look like on Monday morning?" A card that cannot be answered concretely is a wish, not a proposal.
- On an Improve card: "Is this worth improving, or should it be in Drop?"
Common mistakes
- Vague Improve cards. "Improve communication" survives every retrospective and changes nothing. Insist on the specific mechanism.
- An empty Drop column. Teams add far more readily than they remove, and process weight accumulates. Ask the Drop question explicitly rather than waiting for volunteers.
- Overloading Add. One or two new practices per sprint. More than that and none of them survive contact with the next deadline.
- Using DAKI to diagnose. It starts from proposals. After an incident or a sprint nobody understands, run a discovery format first.
- Skipping the review of last time's actions. DAKI produces commitments every session; without a visible check, the same proposals return and the team stops taking the board seriously.
- Ending with five action items. Three is the ceiling that survives a normal sprint.
How to run DAKI in QRetro
- Create a board from the DAKI template — Drop, Add, Keep and Improve are already set up.
- Share the link; participants join in the browser without an account.
- Read out last sprint's action items and mark what was done before opening the columns.
- Run eight minutes of silent writing with cards hidden, then reveal and group duplicates.
- Give each person three votes and work down the ranking.
- Record what changes, who owns it and by when. Stop at three items.
