I’ve been thinking a lot about Scrum lately. That’s nothing new, really — I’ve been scrumming since 2007. We were living in Australia at the time, and my goal was better self-organisation.
My daughter was eighteen months old, and I was spectacularly stressed trying to keep the house running and look after her while her mum was working at the hospital. I’d imagined the whole “working on the side” thing would be easier. So I went looking for better ways to get things done. That year I overhauled my entire work life: I started with Getting Things Done and Zero Inbox (still doing both) and went deep into Scrum. Two of its co-creators were Australian, which might be why I stumbled across it in the first place. Inspired by the Scrum approach, I started planning personal sprints — hoping that one day I’d get to scrum with an actual team. I’m still sprinting, still collecting my daily Pomodori.
Scrum is only for IT projects, right?
Since I’m not a developer, I never got to do proper Scrum with clients. At best it was agile project management, which usually just meant we both used a Kanban board like Trello.
I still believe Scrum works brilliantly for non-IT projects — as long as everyone understands the spirit behind it and commits to it. Recently I decided to become a Scrum Master. If Scrum won’t come to me, I’ll go to Scrum. That also means I’ll probably be writing about it more often from here on.
There’s one Scrum concept I want to pick up here: the DoD — the Definition of Done. I’d heard the term before, but what I hadn’t fully appreciated was the underlying idea: quality assurance. The DoD defines when something is “done” and what state it needs to be in so that the client, the stakeholders, and above all the end users are more than satisfied. And that raises a practical question: how long should you really polish something before you send it off or hit publish?
The Definition of Done
In Scrum, the team defines what “done” means at the start of the project. That way everyone knows that anything moved into the Done column has enough quality and value. The DoD is the team’s quality promise — to each other and to the (internal) customer. The agreed-upon gold standard.
I think about this a lot, especially when it comes to my own blog posts. Most of the time I don’t spend ages polishing. I don’t even know if anyone reads these (and that’s not my motivation either — I just want to write every day). A minimal DoD might look like this:
- The content needs to be coherent and relevant. Not too much, not too little. For longer pieces, the opening and closing should form a bracket around the argument, and the logic needs to hold up.
- Reread the whole thing and fix anything clunky or rough.
- Run it through a spellchecker.
- Read it aloud one last time and adjust the flow.
- Ideally, let it breathe overnight and come back with fresh eyes in the morning. It’s amazing what you spot the next day.
When I’m writing for a client, the text goes through additional checks — SEO, fact-checking, verifying links. I want to make sure the client can work constructively on the piece rather than tripping over rough patches straight away. That still happens, of course, especially in the first version, which at best is an 80-percent approximation. Some clients forget that — and they forget that in a first draft I often have to guess at content because the brief was thin. We clean things up in the final version, the one that actually counts.
I think everyone should have a Definition of Done — or, if you’re commissioning work, issue one. That way everyone has something to work against, and discussions stay objective rather than emotional. That’s the hope, at least.
From the archives of reinergaertner.de, running since 1997. Translated with AI help and my questionable bilingual proofreading. If you spot a Germanismus — that’s a feature, not a bug.