What's the difference between DAKI and Start, Stop, Continue?

DAKI has four columns instead of three. The fourth, Improve, is the difference. Start, Stop, Continue forces every change into a binary (introduce or remove). DAKI lets the team say 'this is mostly working but the handoff is rough', which is a different and often more useful kind of change.

Is DAKI a Scrum thing?

It's most commonly used by Scrum teams because the format translates cleanly to backlog items and the Improve column maps neatly to refactoring tickets. But it works for any team that ships in cycles and needs the retro to produce something visible in the work that follows.

Things working well enough that you want to formalise them, not just tolerate them. The team agreement to write all PRs as drafts first, the new pairing rotation that's reducing context loss, the standup format that's actually keeping standups under fifteen minutes. Keep is where the team converts informal practices into named ones, which is how good practices survive turnover.

How is Improve different from Add?

Add is for things that don't exist yet. Improve is for things that exist but aren't fully working. 'Add a deployment checklist' is an Add. 'Improve the deployment checklist so it actually catches the env var mistakes' is an Improve. The distinction matters because Improvements are usually faster to ship than Adds.

Should every column produce a commitment?

Yes, that's the format's whole shape. If the team can't name a Drop or an Add or a Keep or an Improve worth committing to this sprint, DAKI isn't the format you needed this time. Switch to Rose, Bud, Thorn or 4Ls for a sprint and come back to DAKI when there's something real to commit to.

The toolkit · DAKI

DAKI retrospective

Drop, Add, Keep, Improve. The retro format for teams that want every prompt to produce something they can put in Jira.

40 prompts · 4 columns · free

🗑️

Drop

What should we cut entirely?

10 prompts in this bucket

➕

Add

What should we introduce?

10 prompts in this bucket

🔒

Keep

What should we explicitly commit to keeping?

10 prompts in this bucket

🛠️

Improve

What's almost working but needs polishing?

10 prompts in this bucket

Try another framework

Frameworks that pair well with DAKI.

Start, Stop, Continue

The classic. Three columns, fast to run, hard to argue with.

KALM

Keep, Add, Less, More. Subtler than Start/Stop/Continue.

4Ls

Liked, Learned, Lacked, Longed for. More texture than 3-column.

Or see all 10 retro frameworks.

About the DAKI retrospective

DAKI (Drop, Add, Keep, Improve) is the retrospective format for teams that want every conversation to produce something a developer can pick up tomorrow. Where 4Ls produces texture and Mad, Sad, Glad produces feelings, DAKI produces tickets. The four columns are deliberately action-shaped. Drop names a thing to remove. Add names a thing to introduce. Keep names a thing to formalise. Improve names a thing that's almost working and needs polishing, which is the column that distinguishes DAKI from Start, Stop, Continue. The Improve category gives the team a place to talk about the things that are 80% there, the rough edges that don't yet break the workflow but quietly cost time. Use DAKI when the team is engineering-mature, when retros have been producing lists rather than commitments, and when you need the meeting to translate into something visible in the sprint that follows.

How long does a DAKI retro take?

Forty minutes for a two-week sprint. The discussion is denser than Start, Stop, Continue because every item needs an owner, but lighter than 4Ls because it doesn't dwell on feelings. For a one-week sprint, thirty minutes works. For a quarterly, ninety, with a full half hour spent on Improve.

When DAKI beats Start, Stop, Continue

When the team has reached the maturity where 'Stop' alone isn't subtle enough. Start, Stop, Continue assumes most changes are binary, when in practice many things just need to be done better. The Improve column gives DAKI a higher ceiling: it captures things that aren't broken enough to Stop but aren't good enough to Continue. That category alone is usually the difference between a retro that produces real change and one that produces a list.

DAKI versus KALM

Both have four columns. DAKI is action-first (every item is a thing to do). KALM is gradient-first (every item is a dial to turn). Use DAKI when the team's challenge is producing change, not noticing what to change. Use KALM when the team is already producing changes and needs to fine-tune.

Common mistakes with DAKI

First: forgetting owners. DAKI's whole shape promises action, and items without owners betray that promise. Force the question every time. Second: under-using Improve. The Improve column is the most subtle and gets the least air time, even though it produces the highest-leverage changes. Allocate at least a third of the discussion time there. Third: not reviewing last sprint's commitments at the start. DAKI compounds when the team can see what landed and what didn't. Without that loop, the format quietly degrades into a Drop-and-Add cycle.

Frequently asked

What's the difference between DAKI and Start, Stop, Continue?: DAKI has four columns instead of three. The fourth, Improve, is the difference. Start, Stop, Continue forces every change into a binary (introduce or remove). DAKI lets the team say 'this is mostly working but the handoff is rough', which is a different and often more useful kind of change.
Is DAKI a Scrum thing?: It's most commonly used by Scrum teams because the format translates cleanly to backlog items and the Improve column maps neatly to refactoring tickets. But it works for any team that ships in cycles and needs the retro to produce something visible in the work that follows.
What goes in Keep?: Things working well enough that you want to formalise them, not just tolerate them. The team agreement to write all PRs as drafts first, the new pairing rotation that's reducing context loss, the standup format that's actually keeping standups under fifteen minutes. Keep is where the team converts informal practices into named ones, which is how good practices survive turnover.
How is Improve different from Add?: Add is for things that don't exist yet. Improve is for things that exist but aren't fully working. 'Add a deployment checklist' is an Add. 'Improve the deployment checklist so it actually catches the env var mistakes' is an Improve. The distinction matters because Improvements are usually faster to ship than Adds.
Should every column produce a commitment?: Yes, that's the format's whole shape. If the team can't name a Drop or an Add or a Keep or an Improve worth committing to this sprint, DAKI isn't the format you needed this time. Switch to Rose, Bud, Thorn or 4Ls for a sprint and come back to DAKI when there's something real to commit to.

When not to use it

Sprints where the team needs to talk about feelings or process tension. DAKI's action-shape is hostile to anything that doesn't fit into a Jira ticket. After conflict, run Mad, Sad, Glad. After a hard sprint, run 4Ls.

How to run a DAKI retro

1Block 40 minutes. DAKI's four columns each demand an actionable answer, so give the discussion enough room.
2Open with a sprint recap that lands the team in execution mode. DAKI is not a feelings format.
3Show all four prompts. Five minutes of silent writing per category. Drop first because it's the easiest to start with.
4Discuss in order. Cap each category at five minutes. Force a 'who and when' on every item before moving on. If you can't name an owner, the item isn't actionable enough.
5Vote one item per category to commit to. That's four total. Each gets an owner and a target sprint.
6Send the four commitments in Slack within an hour, with a link to the matching Jira ticket (or a note that the ticket is being created).
7Open the next retro by reviewing what landed. If three of four sprints in a row produce items that don't get done, the issue isn't the format, it's the team's commitment-to-completion ratio.