The DoD, Definition of Done, is used in the agile method Scrum to assess whether a desired delivery object or work package has been completed and/or (fully/correctly) implemented. If the DoD is not fulfilled, the work package is not completed.
Furthermore, there is also the DoR - Definition of Ready. The purpose of the DoR is to prepare a work package in such a way that all information required by the developers (team members) is known. This ensures that a developer can start work right away.
In addition, there are also acceptance criteria. Unlike the DoR & DoD, which apply to all upcoming work in the backlog, acceptance criteria are additionally recorded individually for each upcoming work package.
Sounds pretty easy, doesn't it?
In the real world - out there, in the jungle of software development, we often get stuck. You can't see the wood for the trees and don't really take the DoR or the DoD seriously, although both are actually quite important.
A few days ago I was on the train on my way home and while scrolling through LinkedIn I saw the abbreviation DoD in a post. Nothing unusual, as I follow a number of people and companies who also move in the IT world and call themselves experts in agile. Reading through their complicated explanation of a DoD, funnily enough, it reminded me that the next time I'm shopping in town, I'll finally have to buy a curtain rod that can be clamped in the window frame and I absolutely have to write that on the shopping list because...
Now she's rambling on again, you think. No - she's not 😊.
In fact, the detour to the shopping list story has quite a lot to do with the DoD and DoR. But first things first.
Since I'm a structured, routine-loving person, I plan (except for going to the toilet, though...never mind) almost everything. So, in order for me to go shopping, I need money, otherwise it will get a bit embarrassing at the checkout. Furthermore, I think about what I need for the upcoming week. Mainly groceries, now and then detergent or "extraordinary" things like a curtain rod. I also think about which shops I need to go to so that I can get everything. This is my DoR and acceptance criteria for a weekly shopping trip.
We do the same in our Scrum team when we define a work package (story). We think about what we need so we can start the work. We need the right contacts in case there are problems, the correct permissions for a systems, of course the necessary capacity, the knowhow and so on and so forth.
Based on the acceptance criteria the team, the product owner and the Scrum Master determine which criteria of the DoD, Definition of Done have been achieved. If even one of these criteria is not met, the work package is not completed, i.e. not Done.
Back to the shopping list and my upcoming trip into town. I set off on my "Rolls Royce" as the shoemaker around the corner always calls my e-bike. I tick off one thing after another on the list and go back home. Once I get home, I realise as I'm unpacking that I've forgotten the curtain rod. I roll my eyes at my own goofiness. Now I have four options:
go back into town again and get the curtain rod.
tick off the item and not buy the curtain rod (maybe never buy it).
realise that I don't really need the curtain rod and cross "curtain rod" off the list.
leave the item open and hopefully remember it the next time I go shopping.
There. Perhaps you can already see what I'm getting at.
going to town again is tedious and inconvenient - but the task would be completed. However, the shops are already closed (sprint finish, sprint review). Therefore option 1 falls away.
when I apply point 2, I don't feel satisfied. I set out to do something, but I didn't implement the point. So I am left with this awkward feeling in the pit of my stomach that the buy-in was not successful. (incomplete work package/ story closed contrary to Scrum theory).
good thing I decided against the curtain rod, it would have just stood around at home and annoyed me every time I walked past. (reprioritisation)
the last option is not entirely satisfactory, but the next time I go shopping I will be more focused and if necessary even go to a second shop to actually buy the curtain rod. (Leftover)
Away from the curtain rod, back to our agile team and the DoD.
At the end of each Sprint, every work package is reviewed. For one work package, two out of three acceptance criteria are met. One, however, has not been achieved. Now you, your team and your Product Owner are faced with the decision whether to choose option 1, 2, 3 or 4. As easy as that.
Maybe next time you (I/we) have to explain the DoR, DoD or acceptance criteria to your team, try using a simple example like mine. Why always throw around complicated buzz words when it can be done quite simply?