What is a Drop Add Keep Improve (DAKI) retrospective?
DAKI retrospectives help agile teams think deeply about their processes and identify what’s serving them well and what isn’t. The DAKI retrospective template goes beyond just covering feelings, like the Glad Sad Mad retrospective format. And it adds more nuance than the Start Stop Continue retrospective template. Instead, it prompts scrum teams to go all-in as they discuss what to Drop and Add, and what to Keep and Improve.
Let’s walk through the individual parts of the Drop Add Keep Improve retro template:
What work processes that aren’t serving the overall sprint outcome? It’s important to note this bucket can be debated (you don’t have to throw out everything that gets mentioned under this prompt).
But it encourages teams to think about what deadweight they’re carrying and what is no longer serving its purpose.
Example: Our current bug report template is not serving us. The fields we ask users to submit are too vague, which means we spend too long trying to find and replicate a bug before we can fix it.
Did you just read about a new best practice? Hear about a fancy new tool or technique from an agile coach, product owner or scrum master in another company? Put it in the “Add” bucket.
Like the “Drop” bucket, you don’t have to do everything on this list. But suggesting things to add puts them up for debate with your scrum team and creates a menu of possible additions to choose from. Items in this column may end up as action items at the end of your retro.
Example: I heard about this idea of WIP limits in agile development. I think it’s from Kanban. Limiting what we have on our plates might help us ship more high-quality code and help us stay focused.
What working processes should we keep or continue doing? What’s serving us well?
Perhaps estimating each user story on the backlog is really helping your team plan work better. This is a good place to call out any processes and teamwork practices that are serving the team well – firstly to raise awareness among other team members that it’s a valuable thing, but also to make sure it doesn’t get dropped.
Example: I like the new process of assigning a weekly support lead on our team. I feel like it shares the burden in a fair way and we all get to learn what issues customers run into.
What parts of our work have potential, but aren’t quite there yet? What didn’t go as well as it could or should have?
Perhaps your technical debt workflow is on the right track, but still dragging the team down. If you know how to improve a certain process, you can note that. If you aren’t sure of the solution, simply highlighting a weak spot can spark a deeper conversation. Then your team can come together and brainstorm a potential solution.
Example: Sometimes brainstorming how we approach a solution is difficult asynchronously. I think we could improve our input by getting together in person or on a video call for those tasks.
The key to a great DAKI retrospective
The key to a successful DAKI retrospective is an explicit focus on pragmatism and practicality, not emotions or theory.
DAKIs are only helpful when you analyze everything through the lens of “did this help us reach the sprint outcome?” To do this, you need a clear definition of success in the sprint, and then a logical explanation about why something did or did not support your team’s success.
If something didn’t help you, DAKI gives you the opportunity to not just say you’re sad or mad about it, but to explicitly suggest dropping it.
But it’s not all about getting rid of the old. The DAKI sprint retrospective also encourages agile teams to come up with ideas for new things to try. Whether in the Improve or Add bucket, a DAKI activity helps you coming up with new ways to become more effective as a team.
When to do a Drop Add Keep Improve (DAKI) retrospective
We recommend running a DAKI retrospective activity in three scenarios:
When your team needs a refresh after a long time working together
People fall into habits as they work together, which can hamper the iterative ideology of sprints. A DAKI retrospective breaks that habit and forces people to take a hard look at whether team processes are really working.
When you fail to meet the sprint goal
A DAKI retrospective can unearth good and bad work processes. It helps agile teams quickly identify what’s holding them back and which processes need a bit of extra love. Having this conversation helps your team make an action plan and focus on how to meet the sprint goal next time.
When your team feels like it’s time for a reset
Each time you do a DAKI, you can look at what’s working and not working at that moment, making it valuable for a reset when a new team member joins, multiple folks leave, or some other big change came down the organizational pipeline.
How to run a Drop Add Keep Improve (DAKI) retrospective with Parabol
First of all, jump into Parabol. If you’re a Scrum Master or the team meeting facilitator hit the vibrant Add Meeting button.
Here you can choose a “retrospective” meeting from the carousel and choose whether you want the input to be anonymous or non-anonymous. Now it’s time to generate insights about your last sprint!
Select the DAKI retrospective template
Select Retro Meeting with the arrows, then use the dropdown to select the DAKI retro template. Here’s where you can find other built-in templates such as the Starfish retrospective, Three Little Pigs retro, Working and Stuck, Lean Coffee and many more retrospective ideas.
The Icebreaker box is checked on by default. You don’t have to do one, but we recommend it. A good icebreaker is the prelude to a great retrospective and can loosen everyone up.
When you’re ready, the facilitator should hit Start Meeting to kick things off!
Start your meeting with an icebreaker question
If you’re doing an Icebreaker, you’ll have a random question to answer. You can refresh it if you want another option, and of course you can create your own if you want.
Next, you’ll reflect on your work together using the Drop Add Keep Improve (DAKI) prompts.
Remember, Parabol is a remote-friendly online retrospective tool that enables you to work asynchronously with your team. They can all leave comments together, or do it at a time that works for them. Also, reflections in retrospective meetings are anonymous, and no one can see them until you’re done working on them.
After the reflect phase, you’ll vote on issues to discuss, talk about the most voted on items, and then get a summary of the retro when you’re done. You can export any action items to your backlog with the tool’s Jira integration.
Make sure to review the retro 101 guide for tips on running a great agile retrospective with your team.