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?
Wan't to meet me in person to tell me how stupid I am? You can find me at the following events:
- Spring Data JDBC - New Kid on the block.
- Softwaredevelopment in the 21st century.
- Domain Driven Design mit Relationalen Datenbanken und Spring Data JDBC.
- Kerbal Space Program, Glücksspiel und Psychologie und was das mit dem (Berufs)leben zu tun hat.
- Javaland Freeletics
- Domain Driven Design mit relationalen Datenbanken und Spring Data JDBC
- The New Kid on the Block: Spring Data JDBC