Scrum Rules: As a Team Member I Work With the Team to Expand the Definition of 'Done'

The Definition of ‘Done’ for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint. Expanding the Definition of ‘Done’ until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance.

Team Members expand the Definition of ‘Done’ by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities. When every Team Member is systematically expanding the Definition of ‘Done’, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources. If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.

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. 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 Definition of Done. These apply to every Sprint Backlog Task.

Once these required activities or constraints are added to the Definition of Done, 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 check boxes pre-printed on the cards you use to write Tasks or Product Backlog Items. By separating these out of your Product Backlog Items and Sprint Backlog Tasks, the team has actually expanded their Definition of Done.

There are four general methods for expanding the Definition of Done:

1. Expand the Agile Team’s Skill Set.
   In some ways, this is the simplest and most common approach to expanding the Definition of Done. By training, coaching, mentoring, re-assigning or hiring, a team’s capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team’s development and can increase communication overhead among team members.
2. Expand the Team’s Authority.
   Sometimes, a team is not able to do part of the work because they are not authorized to do so. This may be a policy, an unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every Sprint instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing.
3. Automate an Existing Manual Process.
   Automation is often given far less than its due consideration. This is primarily because automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many Scrum environments, heavy automation is critical and a huge enabler for very short Sprints. Automated testing, automated translation, automated build processes, are all common areas of improvement. Scrum teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.
4. Remove Wasteful Processes.
   There are some parts of the work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval (“rubber stamping”). For example, at one insurance organization their “second stage” approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should “get rid of it”.

As Scrum Teams mature, it is expected that their definitions of ‘Done’ will expand to include more stringent criteria for higher quality. — The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…