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…

The Enabling Requirements Document…

We have all worked in environments where either Product managers or delivery heads in a company give high-level vague requirements. But for some unknown reason expect engineering / Development / Implementation teams to deliver tangible results.

In-fact this is a subject I am talking to a fair few people about in the Agile communities I frequent, most notably the Scrum based ones.

During discussion someone asked what is a good definition or measure that can be used to day if a requirement was suitably defined. After some thought I come up with the following definition, but as usual I have some pre-conditions that help out, so here it goes:

"A Requirement specification is good if it allows a person of average skills to implement the requirement without experimentation."

This means that if the requirement is not clear and needs to be explained more, or if the skills of the team implementing the requirement are not sufficient for the task. There is a great likely hood that any understanding of the requirement may well be incorrect.

The best requirement specification should enable a team with the right skills to implement it. However, getting to this level of maturity in product requirements/feature lists/backlogs can be hard. Also it needs teams to be realistic about what skills they do and do not have, and be able to articulate that will need time to research/be trained/mentored in skills required. Or even articulate that the requirement is just not good enough to work on due to its vagueness.

User stories help a little in this, but for a feature from a product/business focus a definition/specification needs to be created that is not vague and can be used as a basis for story creation.

At Last I decided to get my CSM Certification. (Certified Scrum Master)…

It has taken me around 5 years to actually sit down and get certified, I still find it strange that even though I have used and implemented Scrum many times over the past 5 years. People still want to see a commercial certification.


Guess I will get the Certified Scrum Practitioner next...