Can the definition of done potentially be a bad thing?


#21

Expand to include more stringent criteria for higher quality” certainly sounds like “bigger and more robust” to me. :slight_smile:

Here are a couple of examples that come to mind:

On one project we went several iterations without any persistence. Once we implemented persistence, all future stories were expected to include persistence and all releases were expected to support upgrading existing data.

Similarly with internationalization. Don’t worry about it for several iterations, then implement it by externalizing all our user-visible strings, then expect all user-visible strings to be externalized as part of all future stories.

Are those examples of a definition of done getting more mature, or bigger, or more robust? Or do you not consider them included in a definition of done?


#22

Since the DoD is something that the team works on together, it is specific to that Scrum Team. Each team’s DoD can be different from the other.

I think persistence is a good example. Internalization seems like it can go into the DoD if the team decides it but if it is a feature that we will be adding in the future, this may be not necessary to add to the DoD.

This will be a good discussion point for other members to chime in.


#23

Hi Troy,

I believe you’ve answered your own question. You asked:

Then said:

Sooooooo… just keep reminding people of that 2nd statement. I’d add, perhaps, to say the Sprint Review is also supposed to include a decision whether or not to actually release the increment to the hands of end users. That’s important to remember and causes teams and stakeholders to continually seek a more stringent and evolved Definition of Done. As in: “hmm… are we truly proud to release the work we’ve done this Sprint?” If not, what will we do differently next Sprint and how will revise our backlog?"


#24

Definition of Done is never a bad thing – (notwithstanding the fact it can be understood and therefore practiced badly).

It’s a good thing. Perhaps the best part of Scrum, in my opinion. It’s a powerful feature of the work which helps us make transparent the quality of the product. Here’s an attempt at an analogy which, I think, illustrates my point:

  1. Imagine you’re baking an apple pie.
  2. You add all the right ingredients.
  3. You stir this, knead that, et cetera.
  4. You’ve got the pie ready to go in the oven. It’s “done”, one might say.
  5. But it’s not done. It’s not baked, obviously. And therefore, the quality of the pie crust can’t be inspected, the taste can’t be evaluated. Quality is still invisible. Taste is still imperceptible.
  6. Conveniently, we’ve baked millions of pies in the world and we know it takes less than 30 minutes under the right conditions of heat… so 30 minutes later, you take the pie out of the oven. It’s “done”, you might say.
  7. But it’s not done. It’s still too hot to eat and even thought the pie appears to be convex, there’s still risk it will flatten, sink. It has to cool. We must wait.
  8. After a cooling period…it’s “done”, one might say. But it’s not done. It’s not been delivered and therefore can’t yet be eaten.
  9. So next we slice it, plate it, serve it. Bon Appétit.

At #3 above, that’s the equivalent of Sprint Planning
#4 = works on my machine
#5 = building
#6 = tests are all passing, ready for deployment
#7 = deployed
#8 = it’s been in the production environment a while – perhaps hidden from users, or perhaps exposed to a subset *(like beta-testers or release-ring), tests still passing, all looks good
#9 = in the hands of end users and known to meet their needs.

Because apple pie is a physical object, the metaphor presents stakeholders and team with a means to discuss “done” in concrete terms. Clearly, an un-baked apple pie isn’t edible – clearly, the taste and quality cannot yet be determined. So, to extend the metaphor to software for example, clearly until the software is fully-baked and served on a plate to end users, the quality and usability is unknown.

Hence, if the team’s current definition of Done only includes #6 above, then they and stakeholders ought to work diligently to enhance the team’s capabilities so that they can, every single Sprint, produce something like #9 above.


#25

From The Scrum Guide:

So, yes, we want the definition of Done to grow and become “more robust” – it does so as the market changes, as the needs of end users change. Here’s an example:

In January 2014, our team was working with an enterprise whose lawyer told them they must comply with the EU “Cookie Law” (which should die in a blazing fire in my opinion). So a few Product Backlog Items were introduced to create a disclaimer about cookies, and to implement a P3P Policy (a machine readable doc which explains privacy policy of the website and its use of cookies). But apart from the PBIs, our team acknowledged a new problem – that is, the implementation of subsequent Product Backlog Items may effect or make void the P3P Policy.

Example: Perhaps today, the website doesn’t store personally identifiable information about its users. Perhaps next Sprint, we’ll implement a feature which asked the users their phone-number and stores it in a cookie. That new feature will invoke a change to the P3P Policy document and perhaps to the disclaimer text so that the site always remains compliant with laws of the EU.

So – in effect – the needs of the market had changed and therefore our team had to figure out a way to enhance our capabilities so that we can always be sure the code we ship is lawful. “Done” (I’m referring here to the desirable definition of Done) moved beyond the team’s current definition of Done. It took a few Sprints before it was routine for the team, but soon their actual definition of Done expanded to include (as a normal course of their dev work) reviews of increment every Sprint to ensure compliance to the EU law.

What I’m pointing out here is that a Definition of Done isn’t a “decision” – it’s a condition of our marketplace (what does the market consider “Done”) and simultaneously a condition of our team (what is the team capable of getting Done [not in terms of scope but in terms of quality).


#26

Maybe my title is click bait… :sunglasses:


#27

@Troy, it is :slight_smile:


#28

@David, thanks for sharing your experience. The market changes and end user changes are not the only factors in considering an update to a Definition of “Done”. You are right, it’s not a “decision”!, ultimately it is an artifact that reduces/removes ambiguity while creating the product increment. It’s also about the way the team works together. Adding more weights metaphor - is inspect and revise to make it more robust.

I like your example of baking a pie and is similar to the one I have used for doing laundryhttp://agilekingdom.com/wp-content/uploads/2017/06/Laundry3.jpg