Wednesday, November 14, 2007

Common Scrum Pitfalls - Killing your Scrum with a bad Definition of Done

When I educate teams or even organizations to apply scrum I often hear the question about "What should we include to our definition of done?". In some cases the PO (Product Owner) has set the definition of done (not the team, ouch).. Anyway, since this seems to be very common problem I wanted to address it here.

One common mistake is to introduce something that I call Coverage Killer. In some organizations Test Driven Development has been misunderstood as "creating a lot of tests to get good coverage" - this is wrong due to the fact that "you get what you measure". Imagine that some organizations have gone so far that they started to remove code to get better test coverage percent... duh. Well, you get what you measure ;) This is just part of the problem; when you (or your customer, Product Owner...) set something like "the minimum test coverage is 85%" you are about to introduce an overkill. Your development team will be writing tests just sake of coverage (not for ensuring that your business functionality works, which is far more important than coverage, eh).

Usually the team does not put Coverage Killer into their definition of done so to take care of this issue let your team define it's definition of done. Simple.

Another common mistake is to leave out refactoring from your definition of done. In practice I've seen several teams having "refactor "-tasks or stories in next sprint or even "stabilization" sprints. That demonstrates the fact that team is not committing quality code during the sprint and you could not "release" after every sprint (which should be the case if you play Scrum by the book). Even more scary would be a team not refactoring at all..

So how far you can go with your definition of done? I will get back to this so stay tuned :)


Unknown said...

Regarding who can define "done" for a n agile team, it is very important to not exclude the product owner. After all, the focus in agile development is on producing what the customer wants and not only what the coder wants.
I agree that the team must be involved in the definition of done since a definition they can not commit to is of no use.

Also, as you have experienced, refactoring should never be brought to the backlog level as that only shows that the implementation in the previous sprints really has not been finalised.

Marko Taipale said...

Dan: you are abslutely right. My intention was not to say that the Definition of Done is not collaborative act from product owner and the team.