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.
Ken
Ken Schwaber's Blog: Telling It Like It Is 
Pingback: Artifact Transparency, The Definition of Done | A Learning Path to Agile
Ken, a question. Why the 148 units required. Is that purely a hypothetical or did I miss something important in an earlier blog?
Hi Martine,
Ideally 148 units of work needed to be performed to develop the “done” increment of hypothetical unit of quality software (as explained below in one of the Agile Alliance Founders document) :
Work Item : “Units of work performed by New Scrum teams”/ “Units of work performed by most of the Mature Scrum Teams”/ “Ideal Units of work needed to be performed to make it completely Done”
Requirements analysis : 25/25/25
Design of architectural components :15/15/15
Design review : 0/5/5
Design of tests : 0/10/10
Design Review: 0/3/3
Design of documentation: 0/2/2
Design Review: 0/1/1
Refactoring of existing design: 0/0/8
Design of unit tests for new code: 0/3/3
Writing new code : 10/7/7
Design of unit tests for code to be refactored: 0/3/3
Writing refactored code : 6/3/3
Pair programming: 0/4/4
Write functional tests: 0/4/4
Write integration tests: 0/4/4
Write documentation: 4/4/4
Unit test code : 0/2/2
Identify and rectify defects: 0/2/2
Subsystem/team build: 6/2/2
Identify and rectify defects: 0/2/2
Unit test for subsystem/team code: 0/2/2
Identify and rectify defects: 0/2/2
System/integration build: 1/1/1
Identify and rectify defects: 0/2/2
System, functional tests:1/2/2
Identify and rectify defects: 1/2/4
Integration tests: 0/0/2
Identify and rectify defects: 0/0/5
Performance tests:0/0/1
Identify and rectify defects:0/0/2
Security tests:0/0/1
Identify and rectify defects0/0/2
Regression test:0/2/2
Identify and rectify defects:0/1/2
Documentation test:0/1/2
Identify and rectify defects:0/1/1
Total work expended requirement:78/118/148
Work remaining per requirement:65/30/0
i have searched up and down the agile alliance website for this but cannot find it. could you post a link to it – or to any DoD that is this large? I’m very curious what the deficit of done is within the organisation im currently with…
“Deficit of Done” – That one had me fall out of my chair!!!
i actually found that term while searching for the definition of done on scrum alliance 🙂
“Descaling and the infamous Scrumble result.”
In Scaled Scrum, “scrumbles” should never happen. Each increment should be of “Done” quality with nothing left to be integrated.
Yet Scrum requires transparency over any failure to achieve this standard. That’s when scrumbling, as a mechanism, might reasonably be applied. Embarking on a “scrumble” is an open acknowledgment of a Deficit of Done, and of the need for improvement if Scrum is indeed to be applied at scale. The first step on a death march is the one to be avoided. Scrumbling is a better option than having fake, degraded sprints that no longer observe the standard of quality asserted here.
Pingback: Issue 33 - Agilean Weekly
Regarding the number of “units of work”, I completely agree what the majority of teams do not track (and in many cases do not even consider) all or even most of the items. Not only does this lead to having a “definition of not quite done” it has impacts on nearly every other element of the system.
Laying out the standard process for taking a product backlog item and turning it into something done and usable require thought, collaboration, and an agreed upon approach. Usually not done by teams.
Ken, I could take that two ways….
1) That teams should be doing it, but typically do not.
2) That while it should be done, it is not typically something the team should be doing (ie someone else should do it).
I am hoping you meant the first….
Yes, the first.
Done is a standard of engineering excellence that promotes value creation. We are a profession with values of commitment, focus, openness, respect and courage needed to provide transparent done increment. I wrote another blog about how an SDK (Scrum Development Kit) can be used within a development community to lessen dependencies and make the definition of done more4 stable and visible.
Look at the evidence-based management(http://bit.ly/2pkgyZ8) to see how I think our work should be measured, resulting in improving value creation. Everything else is suboptimal and usual circumstantial.
Ken
Pingback: An argument in favor or Sprint 0 | confessionsofanagilecoachblog
Pingback: Done! | Technology unplugged.