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 done criteria covers items that are addressed in aggregate, instead of at the user story level. Some samples that may apply are listed below.
- Installation documentation has been updated
- Security scans and tests performed and all problems addressed
- Installation scripts have been updated and tested
- Release notes have been updated
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.
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
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”.
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.
