Archive for September 4th, 2009

• Importance of the Definition of Done

  Date: 2009.09.04 | Category: Agile, Coaching, Scrum, ScrumMaster, Team | Response: 0

  I was looking back at some old notes of mine from China and I came across a number of questions from the people I worked with about the Definition of Done.  The Definition of Done (DoD) is a very important concept in Scrum and not spending time to construct a DoD is a common mistake with new Scrum teams.

  In my opinion, the DoD provides visibility and alignment on just exactly what it takes to get a user story completed in an organization.  It could almost be seen as a unstructured value-stream map.  We write down the DoD to illuminate any hidden queues in the organization and to make visible the real effort it takes to complete a user story.  It is also there to protect the Team since it cannot be changed during a Sprint.  Nothing irritates me more as a Team member, or a ScrumMaster, to move the goalposts of a Sprint after it has begun, i.e. adding a new auditing requirement to the DoD.

  The DoD is NOT the same as the acceptance criteria for a user story.  The DoD is an engineering checklist for the cross-functional Team.  The acceptance criteria is the checklist Product Owner and stakeholders use to know if a user story is complete.  They assume all the items in the DoD are complete and if they are not (that is called Design Debt), the Team cannot demo the feature at Sprint Review.  You can think of the DoD as the pre-requisites that need to be finished before a story may be shown at Sprint Review.

  Finally, I have found it better for individual Teams to come up with their own DoD rather than be handed one from management.  When first working with a Team, it is normally better to document what the Team is doing and label that it’s DoD and add to it over time rather than forcing some onerous DoD created by some disconnected process people who don’t even do the work onto an uncertain Team.  Of course, there are some basic standards (code reviews, some form of pair programming, unit testing, etc., etc.) that must be in all DoD, but I find most Teams will include them on their own.

  So what to do when your company has 12 versions of the DoD floating around?  Well, that is why you have ScrumMasters.  It is their job to get the various Team DoD in alignment, not the process goons.  The process goons have good stuff to add to the DoD and Scrum is about collaboration, not forcing other people to do your will.  If the process groups want Teams to do extra work, their requests on the Team are made visible just like everyone other.