Is Your Definition of Done FINISHED?

The Definition of Done (DoD) is the one definition mentioned in the Scrum Guide. If you’re in a team that is practising Scrum, then I hope you have one. Whether or not your Definition of Done exists, FINISHED is a great initialism to guide you in creating and reviewing it.

Functional

Undoubtedly, the essential aspect of getting a Product Backlog Item (PBI) to Done is ensuring you have fulfilled the purpose of that Item. If you’re using a User Story format, the purpose is the part that begins ‘so that…’ You’ll also need to make sure any and all Acceptance Criteria are fulfilled.

Integrated

In Scrum, an Increment is the previous working state of the Product, in addition to the work delivered by this PBI or Iteration. In other words:

Previous Increment + Current Iteration = Next Increment

The commitment of the Scrum Team to the Sprint is to deliver a working Increment. That means your team must successfully integrate every PBI without breaking or unexpectedly changing the behaviour and functionality of the previous Increment.

No Known Issues

This is easier than it sounds, I know, but any known issues that have arisen during the testing process must be addressed and resolved.

Inspected

This word comes up all over the place in Agile! Have all of your team’s stakeholders and peers looked at the work to check the quality is up to scratch?

Developers may want each other to review their work. In Scrum, Developers are the people who have the skills required to deliver a valuable Increment. So, don’t think I’m only talking about software developers here because I’m not. Anyone who has produced output to deliver this value should be peer-reviewed: the PO, Business Analysts, Software Developers, Testers, etc.

Your team should also be asking stakeholders for feedback as early as possible so that when the Increment is delivered, everyone receives exactly what they expected.

Supportable

It should be obvious that you’re going to be supporting this Product for the foreseeable future, so making sure that it is as easy as possible is key. If you’re in a software developer environment, building to clean code principles will help with this. Perhaps you have a wiki for Developers to keep knowledge about the Product within the organisation regardless of whether or not the people who have created or modified certain parts of it are. It’s also a good idea to create support notes for features so your first-line people can solve as many of your customer queries as possible.

And what about deprecation? At some point you may no longer need this feature, so considering early how you can disentangle this part from the greater system may even help you to develop a more sustainable feature in the first place.

Honours Standards

Making sure that work complies with guidelines, standards, and any relevant compliance can help avoid problems in the future. Standards can be community good and best practices, in-house practices, usability standards, etc.

You may need to comply with legal and audit requirements, such as GDPR, so having them baked into your DoD will help to avoid missing them and returning to this later when you’ve forgotten the details of the PBI.

Essential Documentation

We’ve covered some of these in earlier points, such as audit requirements, developer wikis, and support notes. You may also want to consider and release notes you wish to send out. Also, keeping a list of features and what they do can be surprisingly valuable.

Deployment Ready

This is where you think about anything your team needs to complete to be able to hit the big red release button. This could include anything from build configuration to scheduling downtime.

Review Frequently

It’s important to remember that the Definition of Done is only any good as a living document. The whole Team is responsible and accountable for both maintaining it and living up to it. I like to have some time in the Team calendar to review the DoD every quarter, to make sure that we haven’t forgotten what’s in it and consider whether or not we need to change it.