Agile Technique: The Definition of Done?

Definition of Done should be a hygiene factor not an end in its own right. It's there to ensure things are done correctly. Where Definition of Done is good, is to remind the team, that, for instance a story is not completed before it's tested and all bugs are fixed: developers often feel that they are done when code has been committed for the first time. Rarely the case. On occasion there were conversations between the team and the Product Owner about whether some items in the Definition of Done could be sacrificed in order to meet a particular deadline. These conversations were open and constructive. On many occasions, the Product Owner decided not to sacrifice the Definition of Done and to take the hit on the delivery date because they understood its importance to the long-term quality of the codebase.
On technique is about trying to get teams to use several definitions of Done to consider different testing needs. For example Feature Done and Story Done are different. If you look at the types of testing for these 'levels,' you might be more creative about what kinds of testing we do when. Of course, you would like to do everything all the time, but it is not always possible. One example might be browser compatibility or testing on many devices. Not part of story done, but is definitely part of feature done.
The Definition of Done as a mutually agreed upon minimum set of standards. Different people have different ideas of what "done" means, depending on their background, maturity, skill, opinions, etc. Getting a team to a common definition makes assumptions explicit. The Definition of Done is an essential tool which should be agreed by the team and Product Owner - nothing is 'imposed'. Some high-performing teams see it as an important contribution to the organization's perception of their team's professionalism and success.

What the story is, what it will be when it is done, what testing goes on, are a continuing conversation. Definition of done is to assess feasibility, not for detailed requirements or outcomes. Therefore, overly detailed grooming is also often a waste of time, it’s all about using it as an agile technique to enforce communication and deliver better quality projects.
Follow us at: @Pearl_Zhu
Published on March 15, 2015 23:28
No comments have been added yet.