Defining "done" in an agile project

23 September

I’ve been teaching a number of agile courses lately and working with some teams around the world kicking off their agile projects, and I find a common challenge that teams are facing is defining "done" for their stories.

The Agile Manifesto has as one of its core values “we value working software over comprehensive documentation” and one of the principles is “working software is the primary measure of progress“. Both of these statements often get interpreted as meaning the only thing the agile team should care about is delivering software that runs.

My understanding of “working software” or a working solution is wider than compiles clean, usable or “works on my machine”.  To me "working" means a stable piece of software that is in the production environment and delivering value for our customers. Frequently, there are a number of important steps that need to be taken to deliver this working software or solution, and many of those activities extend beyond writing code.

When coaching teams that are starting an agile project, one of the activities I take them through is defining the Definition of Done for the project. We start by brainstorming all the tasks that need to be done to take a user story from a one-line statement of need through all of the steps and stages that are needed to get the functionality into the production environment. We then sequence the tasks into a logical order and prioritise them – which features or functionality is REALLY necessary and which could we leave out without damaging the overall value of the product and project.

Typically we end up with a list of 10-15 tasks that need to be done for every story and a smaller list of things that will be important for some stories.

Here’s an example from a recent team:

  • Story has been identified
  • Elaborated to Acceptance Criteria
  • Quality criteria defined
  • System test cases identified
  • Automated tests built
  • Coded to standard
  • Peer reviewed
  • Unit tests built
  • Unit tests passed
  • System tests passed
  • Meet quality criteria confirmed
  • Release note written
  • HTML help written
  • User Acceptance tests identified
  • User Acceptance tests passed
  • Exploratory tests completed
  • Translated (if needed)
  • Installer script built
  • Installer script tested

As you can see delivering these tasks is much more than just writing and compiling the code. This is quite a lot of work for a cross-functional team.

When you start your project with a clear understanding of what "done" REALLY means then you don’t end the project with work outstanding, and the project delivers real working software.

What constitutes the definition of done on your project?

 

Post by Sharon Robson

CHAT
EMAIL
CALL