Overview

Agile Testing Days Berlin – Promoting the use of a quality standard by Eric Jimmink

No Comments

Are you now or have ever been … on a team that was pressed or overruled into releaseing flawed or unfinished work? I guess everybody has. After in introduction to Scrum he comes to the value of the “Definition of Done”. How it helps to have consensus and common understanding, manages expectations so that a release does not surprise the customer and have repeatable quality.

You should have a Definition of Done on different levels, for Tasks, Stories, Sprints and Releases. For example:

Definition of Done for a Story:

  • all code checked in
  • all unit tests pass

Definition of Done for a Sprint

  • all story plus
  • PB updated
  • performance testing
  • architectue diagrams updated
  • all bugs closed

Definition of Done for Release to INT

  • Installation Package created
  • operations guide updated
  • trouble shooting guide updated

Definition of Done for a Release to PROD

  • stress testing
  • performance tuning
  • network diagram updated

This is starting to look a lot like milestone exit criteria, documents to update and create, because they are on the checklist. In my opinion, many of the tasks from Release to Int/Prod should actually be tasks within the Sprint, when the document needs to be updated, and not something that happens after and outside the Sprint, as the same people are needed to do it.

Interesting figures: 25% of the teams post the DoD on the wall and 25% of the teams are getting the most out of agile, of course that does not mean that they are the same 25%, but there should be some overlap.

The test plan can easily be derived from the Definition of Done and the Product Risk Analysis. A good point that Jimmink makes was that with the Definition of Done in place, you could possibly spot lacking skills. Also the Definition of Done is a team commitment, even a company commitment and best practice. If the DoD is violated, everybody should care. After some points about what the value of the DoD is, how it can be introduced and what the role of the tester is, the session concludes with the finding that a quality standard should not be optional, and teams should embrace the concepts.

Good points in the discussion that followed the session:

  • Mitigate the risk that you blindly check off the points in the higher level DoDs (Sprint / Release), by taking a probably existing company policy as imput, but agree with the team and customer on what is really needed from that.
  • Don’t be afraid to take things off of the DoD
  • Revisit it regularly in the Sprint Retrospective. Do we still meet it? Does it make sense?

Definition of Done for a Story:

  • all code checked in
  • all unit tests pass

Definition of Done for a Sprint

  • all story plus
  • PB updated
  • performance testing
  • architectue diagrams updated
  • all bugs closed

Definition of Done for Release to INT

  • Installation Package created
  • operations guide updated
  • trouble shooting guide updated

Definition of Done for a Release to PROD

  • stress testing
  • performance tuning
  • network diagram updated

This is starting to look a lot like milestone exit criteria, documents to update and create, because they are on the checklist. In my opinion, many of the tasks from Release to Int/Prod should actually be tasks within the Sprint, when the document needs to be updated, and not something that happens after and outside the Sprint, as the same people are needed to do it.

Interesting figures: 25% of the teams post the DoD on the wall and 25% of the teams are getting the most out of agile, of course that does not mean that they are the same 25%, but there should be some overlap.

The test plan can easily be derived from the Definition of Done and the Product Risk Analysis. A good point that Jimmink makes was that with the Definition of Done in place, you could possibly spot lacking skills. Also the Definition of Done is a team commitment, even a company commitment and best practice. If the DoD is violated, everybody should care. After some points about what the value of the DoD is, how it can be introduced and what the role of the tester is, the session concludes with the finding that a quality standard should not be optional, and teams should embrace the concepts.

Good points in the discussion that followed the session:

  • Mitigate the risk that you blindly check off the points in the higher level DoDs (Sprint / Release), by taking a probably existing company policy as imput, but agree with the team and customer on what is really needed from that.
  • Don’t be afraid to take things off of the DoD
  • Revisit it regularly in the Sprint Retrospective. Do we still meet it? Does it make sense?

Comment

Your email address will not be published. Required fields are marked *