Friday, November 27, 2009

What is the definition of Done.

Seems I am being asked this question a lot in agile groups all of sudden. So lets see if I can put my definition on paper as it were.

Ok first and foremost I hate percentages, the reason for this is that they really mean nothing when it come to determining when a project can be delivered or not.

A good example of this is the team member that always says that his work is almost done, and when you push its 80% or 90% done. Yet a few days later it is still 80-90% done. To me work is either 100% done or 0% not done, there is no in between.

Now my view percentages is out of the way, what do I term as done in Scrum or indeed any development methodology.

That is quite simple a piece of work is done if it can be demonstrated as working according to its requirement/feature definition or User story. It is confirmed as being done if the product manager signs it off as being done. Most requirements should have a description of the feature, a description of how to test it, and ideally if its a code based deliverable – unit tests proving it works at system level for any output of the code/api based on known inputs and expected good/bad results. It can also include documentation artifacts as well.

Now next comes the catch, the definition of done should be defined by the team doing the work and the Product Manager if one is available. By no means is the list above exhaustive nor is it the minimum of what should be done. However it is the minimum I  would like done when running an agile team that understands TDD.

I love unit testing, it saves just so much time… ok I digress…

No comments: