Stop versus Done, Part 2 of 2 David Bulkin

This is part two of a two part post, so if you didn’t read part one yet, you can read it now.

Per part one, it is easy stop work on fine grained tasks without ever getting anything to the point where it is truly done.

Good agile teams have just a few stories in play at a time, and use the story acceptance criteria as the most basic definition of done.  They also include additional generic criteria at the story level that must be met, such as the code is checked in.

At the feature level, we rely on the product owner to define done, as they decide if the stories already completed address the feature sufficiently enough, perhaps to the point where no further work is required for that feature.

In this post we will look beyond the story and feature level to the sprint level and beyond.

 

 

Sprint Level Criteria

Sprint level done criteria covers items that are addressed in aggregate, instead of at the user story level. Some samples that may apply are listed below.

  1. Installation documentation has been updated
  2. Security scans and tests performed and all problems addressed
  3. Installation scripts have been updated and tested
  4. Release notes have been updated

 

 

Why not at the Story Level?
 
Getting to done earlier rather than later is a good thing so you could specify the above criteria at the story level.  One way of deciding if criteria should be applied at the sprint level is to ask if it will be best for one person (not necessarily the same person each sprint) to be responsible for this criteria for all stories in a sprint.
 
As an example, you want one consolidated set of release notes that is coherent across the team.  It is easy to have one person be responsible for updating the notes getting input from the rest of the team.
 
Why not at the Release Level?

The criteria that we listed as sprint level, could be story level criteria, but most teams, especially those new to agile, do the reverse and keep them as release level criteria.

For example, security testing is frequently deferred until just before a release, generally because it is painful to deal with the large number of exceptions found.

Does waiting make it less painful, or does it just push increased pain off until the future? 

The simplest way to make the pain go away is to perform the security test more often, perhaps daily (maybe even with each story, thus making this story level done criteria). The fast feedback simplifies the remediation work.

Across Multiple Sprints

 
We prefer not to defer, but there are some things that may best occur outside the context of a single Sprint. One common example is performance and load testing.

Perhaps the test environment we need costs several million dollars and is shared across several teams. In this case, maybe we only get a testing window every other month for a week. Assuming two weeks Sprints, this means that our done criteria must span four Sprints.

What happens if we find serious performance issues after four sprints of work? 

  • Do we have to unwind many hours of work?  
  • Do we have to create multiple branches of code? 

Ok, you already got that point, delaying the feedback cycle is a bad thing. But let’s assume, that in our example, we simply can’t get to the performance environment more than once every other month.

Would it be possible to do performance and load testing on a scaled down environment that would shorten our feedback cycle and allow us to address most issues early?

  • In many cases the answer is yes, if so, you can include “Passes load and performance test on scaled down environment” as part of your sprint level done criteria.
  • Your release level done criteria can then include “Passes load and performance test on environment that models production”.
Release Level
 
There should be little deferred to the release level.  Items that are truly release level should generally be at the periphery of the teams work, like training for the impacted staff, assisting with verbiage for the sales campaign, etc.
Closing
 

Create your done criteria to ensure rapid feedback and recognize that deferring the point at which you reach done likely increases pain and complexity, while balancing this with the need for your done criteria to be practical.

As always, feedback is welcome.

Questions?