Three Ways of Expanding the Scrum Definition of “Done”‎

This article provides some good software-specific examples of how a team might expand their definition of “done”.  This is one of the hardest concepts for most organizations because it is not a “should-be” definition, instead it is a “what-was” definition.  Should-be’s come from management and are imposed on the team.  What-was, on the other hand, is just a simple recognition of reality.

The ‘Definition of Done’ is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the ‘definition of done’ from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the ‘definition of done’ and when do we do this?

Identify Repeating Tasks

Early on, the team will make tasks that include every activity that is done to make software out of the features listed in the Product Backlog.  This will include all sorts of things including “Build login web service”, “Write unit tests”, “Review code”, etc.  Most of these tasks will be thought of in terms of who will be doing them so that throughout the Sprint every person on the team is busy with tasks and there is very little passing of a single task from one person to another.  In other words, one task = one person.

It will quickly become clear that there are a number of similar or identical tasks that show up for most items in the Product Backlog.  If you have to develop a user-visible feature or function in the software, you always need to check code into your version control system, you always need to do some sort of testing on the code, etc.  So you might have tasks in the Sprint Backlog called “Internationalize login panel”, “Internationalize registration panel”, “Internationalize login error panel”, and so on.  Every Product Backlog Item has an “Internationalize ….” task.  These tasks can be abstracted and the “Internationalize” idea becomes part of the Definition of Done (DoD).  It applies for every Product Backlog Item.

You might also have common pairs of tasks where one of the pair is unique to what is being built, and another is attached to it, but common across many pieces of the system.  For example, you might have a task “AnonymousUser class” and an associated “Unit test AnonymousUser class”.  Then you might have another task “LoginErrorHandler class” and an associated task “Unit test LoginErrorHandler class”.  Again, the idea of unit testing then can be identified as part of the DoD.  These apply to every Sprint Backlog Task.

Once these required activities or constraints are added to the DoD, you can then stop identifying them as separate tasks.  Instead, they get represented in some other way in your work environment: a checklist on a whiteboard, columns in a spreadsheet, or checkboxes pre-printed on the cards you use to write Tasks or Product Backlog Items.

Prepare for Release

The software might need many things done to it or around it to prepare for a release.  Often, these things will be put on the Product Backlog  as non-functional business requirements.  For example, it may be important to write online help for the system and this is not currently being done by the team.  The Product Owner identifies that users will need this help and puts it on the Product Backlog.  Yo(1) discovers that These things can eventually be moved into the DoD.  For example, yo puts “Online Help” in the Product Backlog and prioritizes it somewhere near to the point in the Product Backlog when the system will be ready for a release.  The team eventually gets to this item and does it during a Sprint.  At this point, the system is “caught up”, but in order to prepare for the next release, the Product Owner will have to put the same “Online Help” item on the Product Backlog again.  Instead of doing this, it can be added to the DoD.

It is critical that the team agree to add these things to the DoD, and not be forced by someone.  If the team does not feel that it is within their capacity to include something in the DoD, the ScrumMaster should find ways to assist with this: training, etc.  Once something is added to the DoD, it must be completed every Sprint in order to have a successful Sprint.

Release/Deploy to Users

There is nothing like actually getting software into the hands of users to find out what “done” really means!  Similarly to preparing for a release by adding things to the Product Backlog, the team may have a “release sprint” or a “stabilization sprint”.  Everything that is done in one of these special Sprints could and probably should be added to the DoD sooner rather than later!  Again, the team must agree to doing this expansion of the DoD and be supported by the organization so that they have the capacity to meet the DoD every Sprint.

[This article was originally published on Agile Advice on 09-Apr-2008]

If you find this useful, please consider contributing with our
“Value for Value” model.