I think it is a must in an agile team.
The Definition Of Done is a good starting point for a new team or a new software that a team should begin.
In fact, from my point of view a DOD is not just related to a team, but to a team bound to a specific project.
In theory every agile team should have only a software (or a part of it) to deal with, but my world is not so well compartmentalized and it happened that my team had to work on multiple software even if, luckily, not often at the same time.
In any case the point is: hardly a DOD used for a software was good enough for another software.
How to define a DOD?
I don’t think that it exists an omni-comprehensive answer, for sure it is a good idea to start with something simple, few rules in the list and add new rules or change/remove the old ones after few sprints and a good retrospective.
Try to avoid to make changes in the DOD in a running Sprint unless the rule is clearly disruptive for the Sprint itself.
The new teams are often very enthusiastic and they try to be very strict, putting a lot of rules, but instead to drive a good development, they achieve the only goal to make the team uncomfortable with the DOD.
When it happens probably every team member will start to drop the rule/s he/she thinks is useless or too expensive compared to the supposed benefit. At that point no one in the team is able to determine the quality of the story because no one is able to know which rule/s in the DOD has been skipped.
So a good starting point is to be realistic and to avoid to put rules whose value is not absolutely clear.
Well as I said above it is different for every project and in any case is mutable, but we agreed that some rules will work for us in every project:
- The story should be developed in Pair Programming; when it’s not possible, the code should be reviewed at least by another member of team.
- All automated test (Unit test generally) should pass
- The code should be tested on a test server
- The tester should be anyone not involved in the development of the story
In a project consisting mostly in a REST API we have the rule: if the story is about a public API, it should be documented.
Documented software in the DOD
As a user of a lot of third party softwares I’m a big fan of the documentation.
Often the documentation is why or why not I decide to start with a new framework/library/software.
At the same time, as developer, I admit that the documentation is a very complex topic and commonly it is the first thing a team (or the management) skips if it’s not forced by the business of the project (REST API?).
The point is that if you want to have a good documentation you need to put a lot of effort on it and sometimes you need dedicated people that knows how to write a good documentation.
If you need to document an API or a SDK maybe the team has the skills to write a good documentation, but probably only for the “reference” part of the it.
What if you need to create one or more “How to …. with my wonderful SDK”?
Or worst, what if your software is a Backoffice? The team is able or has the time to write a “End user handbook”?
When your software is growing and changing very fast, do you have the time to update the documentation accordingly? Do you even remember it?
When I read the index of a book it seems quite obvious, but when I try to write the index of the documentation I pray to be struck by a thunder.
After three years of developing software with or without a documentation, I admit that to put “the feature should be documented” in the DOD shouldn’t be only a team decision but, as for the other assets that a Company should provide to make the dreams come true, even other people with very specific skills should be involved in the process.
So, do we document our features? It depends. If we think that it’s possible to make a good work (like for the REST API), sure!
In any other case we prefer to be realistic and we decide not to waste time to provide a meaningless/out of date documentation.
Are there some rules that I prefer to omit by default?
I don’t think it exists a wrong rule by definition, surely it’s a good idea to avoid that the DOD becomes a complicated if … else if … else if … workflow.
It should be a very quick checklist to learn and to apply, so I don’t put too much rules depending on the feature or the technology.
The only “if” we put it was about the documentation. It was valid only for the Public REST API features.