Quality, Done Increment

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:

Undone

“Done” is an issue for single Scrum teams. “Done” is the defining issues of all scaled Scrum efforts.

Ken

10 thoughts on “Quality, Done Increment

  1. Pingback: Artifact Transparency, The Definition of Done | A Learning Path to Agile

    • 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

  2. “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.

  3. Pingback: Issue 33 - Agilean Weekly

  4. 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….

  5. Pingback: An argument in favor or Sprint 0 | confessionsofanagilecoachblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s