This document discusses the importance of having a shared Definition of Done (DoD) between all parties involved in a project. It explains that without a DoD, different stakeholders can have conflicting understandings of what constitutes "done" work, leading to broken expectations. The document recommends introducing a DoD as early as possible in a project. It should be created collaboratively with input from customers, teams, and management. Automating checks against the DoD helps ensure work is truly done before moving forward. Continuous inspection and adaptation of the DoD also helps address problems over time. Having a DoD establishes a common vocabulary and allows the team to work together effectively to meet goals.
19. What all of them have in common? With fast delivery And good quality Done product At low price
20. Why in real life it is not so simple? Whhhyyyy?!!!
21. “Uncommitted stuff” Can I start testing this new feature? Yes, it is done! But I can’t even build the product… Ops, I forgot to commit some files...
22. “Useless build” Well done! Let’s deploy new build on production server. Not so fast. We need to do integration testing, prepare DB migration scripts, etc. I hope it will be finished in a week. ???
23. “Unstable velocity” Well done! Our velocity in the last iteration increased up to 32SP. Let’s use it as base line. Agree, but we have to make some small fixes, finish testing and update documentation. How will it change our velocity? Let’s say 20.
24. “Unverified tasks” WTF! A new order form is nightmare. It looks like random set of fields and doesn’t accept basic values. Have somebody tried to use it before assign to me? Don’t panic! I just made a quick fix…
25. “Forgotten requirements” Guys, as we discussed on the planning meeting, we’ve just started pre-orders program for iPad2. And now our site is extremely slow. John, have you made load and performance testing? Well, but …
27. Hidden conflicts in goals Developers like always implementing interesting features, but customers want working software Team want to show productivity, but customers want predictability Developers believe they are perfect, but customers want software without defects Management want to deliver in time, but customers want ready to use software Developers see technical side of the project, but customers see it from end users perspective
28. And the main reason is … Everybody has his own definition of words ‘done’, ‘fast’, ‘low price’, ‘good quality’!
49. Depends on context End of sprint 1 End of sprint 2 End of sprint 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 End of iteration 1 Start of stabilization End of project week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Traditional approaches PM: Are tasks done? Devs: No. PM: OK, go on. But don’t forget about new features. PM: Done? Devs: We hope so. End of project Scrum PM: Done? Devs: Yes. PM: Done? Devs: No yet. End of project week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Kanban PM: Done? Devs: Of course! PM: Done? Devs: Of course!
59. Conclusions Common vocabulary helps us to avoid hidden conflicts … … and work together as a team to archive our goals!
60. Introduce “Definition of Done” ASAP to avoid broken expectations All parties must take part in definition process Automate as much as possible Don't lie yourself, DONE means DONE Learn from your mistakes Inspect and adapt continuously