The Definition of Done is Dead. Long Live the Remember Remember List
In our Scrum team we had a problem with our Definition of Done. We created it at the very beginning to specify what had to be done for finishing a feature.
But time went by and we added cross cutting functionality to the application. So every feature now needs consideration with respect to access rights. It needs a pretty icon most of the time. Of course if it touches the database, we need to modify the scripts for creating the database. But we also sync our data with another system, so that syncing process needs to adapted. If the new feature contains a new interface, that interface needs to be configurable so it can work against dev, test, qs and production systems. And so on …
The list became longer and longer. It’s no longer the simple short Definition of Done we started with. It isn’t simple either. Because there are a lot of things on it, that only apply for certain kinds of stories. So developers started to neglected the DoD and missed technical requirements.
We changed the process.
When attacking a new story we sit down, go over the check list and create a list of technical acceptance criteria on the back of the story card. We call it the Remember-Remember-List (or actually that’s how I translate the German name). Now every developer has the things to remember right in front of him, next to the business requirements.
Is a simple Definition of Done enough for your project? Or do you need something more sophisticated?
What you describe are just acceptance criteria or subtasks. That doesn’t make a DoD useless, they just should be part of it. Both are part of the quality contract with your Product Owner. It’s a good idea though to clean up the DoD from time to time, generalize a little, adapt it and keeping it simple.
@Fabian Exactly, those are acceptence criteria, many from a technical side though (the user doesn”t care if an interface is configurable, she just want it to work in production)
Depends on what you call ‘technical’. If there wasn’t a need for configurability you could hardcode it. Users of a software are not only ‘end-users’, also sysadmins are users, that might need your configurability which should be in the interest of your product owner and other stakeholders, even if it’s not clear for them in the first place if they are non-technical. But that’s what planning meetings are for.
IMHO your team misinterpreted the Definition of Done. DoD is not story specific it is for all stories. Our team’s DoD says “Story is implemented, dev tested, deployed to QA environment and QA tested”. DoD relates to a process not to particular technical/business details of a story. It answers the question “Can we say a story is done?”
Hi Roman,
in a sense I agree with you. It is no longer the ‘normal’ definition of done. But the remember remember list contains all the stuff that needs to be done to call a story done.
So it is similar but different. That’s why I wrote about it
Does it work? Ask me again after a couple of sprints.