Project manager often rely on detailed task lists to monitor progress. The thought is that having lots of fine grained tasks provides visibility.

Unfortunately it is easy to get lost in the details and we often end up being lax in determining if a task is truly complete. As such, we simply consider a task done when the assigned individual stops work on it.
Just because work is stopped, doesn’t mean that anything valuable has really been done.

Good agile projects track just a few user stories (instead of many tasks) at a time and apply strict criteria, specified in advance, to determine when a deliverable is truly complete, e.g. done.

This post, and the follow up, help your team define done criteria at various levels, from story to release, in a way that will engender fast feedback and increase effectiveness to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.

In this first post we will look at the basics, user story and feature level definitions of done.
Story Done

A user story is not done until it meets all story acceptance criteria and has been accepted by the product owner. In addition to the user story specific acceptance criteria, teams should have generic story level specifications similar to the following.
  1. Code has been checked in
  2. The agile lifecycle management tool and task board have been updated
  3. Testing has been performed and the code passed
  4. Code has peer reviewed and approved (e.g. code is clean)
  5. Automated testing is in place for the code
  6. Help system has been updated to reflect changes to the story

 

Don’t Defer Testing
 
In all cases we want to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.
 
A primary example is testing which we have included as story level done criteria. All too many teams defer writing test cases for a story until after the coding is stopped.  This means that in most cases the code is not tested until the subsequent sprint.
 
Testing a sprint behind defers feedback and results in a cascade of complexity as we eventually have to resume coding that we had previously stopped (e.g. we weren’t really done).
 
For example, assume we are in Sprint 12. What happens when find a large number of bugs in the stories that we stopped coding in Sprint 11?
    • Do we stop work on the user stories planned for Sprint 12?

 

    • Do we continue some work on our planned stories and spend some time fixing bugs?
    • Or do we just defer the bug fixing to Sprint 13?

 

When when we stop coding and then do testing, we are really not done coding because testing will find bugs. As such testing should occur roughly in parallel with coding and be completed in a single sprint, meaning our story level done criteria should include that all tests have been executed and passed.
 
Help System Updated, Another Example
 
The update of a help system is interesting as, with testing, it is often deferred.  In the case of help systems, they are often specified as release level done criteria.  The logic is that the technical writer is a part time team member and teams want to have everything in place for them.
 
Our goal is to make the team and organization more effective, not to optimize the performance of the technical writer. 
 
Documenting a user interface is a great way to help with quality. If a UI is hard to document, it is generally also hard to use, so if we work on end user documentation in parallel with the development work, the feedback informs and improves our design.
 
So include the help system update as a story level done criteria (or perhaps you can include as sprint level criteria if your sprints are generally focused on related changes) and modify your teams approach, by sharing the writing load or by getting more writing resources. 
 
Feature Level Done

The done criteria for a feature (e.g. something to big for a sprint, a.k.a. an epic) can be viewed as getting to done on enough of the high priority child stories (e.g. the sub stories) to the point where the product owner believes that no more stories should be worked on.
As most good agile teams have learned, this means that we often decide not to work on many of the original user stories we created. Sometimes the best decision we make is what not to work on!
 
Closing

In summary remember not to confuse stopping work with being done, don’t defer to later what you can do now, and also remember that you don’t need to do everything you originally specified (e.g. less can be more especially at the feature level).

In part two, we will look at definitions of done for the sprint level and across sprints.

Categories: ,

Recent Posts

Think Differently…Using LLM Throughout A Project

Goldilocks and Agility: The Path to Just Right

Global Agility + Innovation Summit 2025

Exploring Models and Frameworks: Simplifying Complexity for Agile and Lean Practitioners

Reimagining Work: Applying a Product-Centric Approach at the Federal Government

Shoulder-to-Shoulder: Decision-Making Tactics in Agile Portfolio Management

Featured Posts

Agile Caravanserai – Bob Martin

Agile Caravanserai – Jim Highsmith

Agile Caravanserai Mary Lynn Manns

Agile Caravanserai Diana Larsen

Agile Caravanserai Johanna Rothman

Agile Caravanserai Dean Leffingwell

Questions?

Contact