Every Sprint in Scaled Professional Scrum requires a completed, ready to ship increment of functionality. The ubiquitous “definition of done” spells out the characteristics of such an increment.
The end result should include software that has:
- Presence of valuable functionality for customers to use;
- Absence of low value functionality that must be maintained and sustained regardless;
- Quality code base to predictably maintain and sustain;
- Quality code base to enhance without undue effort or risk;
- Ability to catch defects early and no later than at release;
- Predictability of schedules; and,
- A Lack of surprises.
Which raises the question, what is quality software? To me, it has these characteristics:
- I can readily understand the software and where & how things happen;
- When I change or add to part of the software, there are no unintended or poorly designed dependencies;
- I can read the code without looking for tricks or poorly defined and labeled variables or data;
- I don’t need the person(s) that wrote the code to explain it to me;
- There are a full set of (automated) tests to check that the function works as expected;
- When I change something and add to the tests, I can check that the entire change and product continues to work;
- How things work and hang together is transparent;
- Standard, well-known design principles have been adhered to.
In terms of relative work units, a hypothetical unit of quality software requires 148 units of work to develop a “done” increment. I’ve found that the average new Scrum team only inputs 78 units of this work, and many mature Scrum teams only perform 118 units
Scaled Scrum requires all Scrum teams to develop quality software, and that software be integrated into one quality increment. If one or more of the Scrum teams does not, the entire increment becomes flawed. Descaling and the infamous Scrumble result. The result looks like:
“Done” is an issue for single Scrum teams. “Done” is the defining issues of all scaled Scrum efforts.