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.

1. How to be proud when you are done

3. 6+ years in software development

4. 4+ years of working by Agile methodologies

5. Expert in Agile engineering practices

7. Agile volunteer

8. Certified Scrum Practitioner

9. Coordinator of translation of the book "Scrum and XP from the Trenches" and “Kanban and Scrum – making the most of both” into Russian

11. No overtimes

12. No bug fixing

13. Clean code

14. More features

15. In time delivery

17. Predictable plans

18. On budgetTeam Customer

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 …

26. Why this happens? Whhhyyyy?!!!

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’!

30. a checklist of valuable activities for …

31. gates your product has to go through before …… you can label the product “Done“

32. 4 mainquestions

33. How to start? Take from previous project From code quality in mind From business problems and wishes

34. Start from flow visualization Image from HenrikKniberg book “Scrum and Kanban - making the most of both”

35. Who should define? Customer Team

36. When to define?

37. Where to store? Electronic More common More personal Paper

38. 3 main formats

39. Plain list

40. Different levels of granularity

41. List categorized by level

42. Complex structure

43. 3 main control principles

44. Automation Use SVN hook for verify comments in commits Add static analyzer to build

45. Fixed workflow Task tracking system can help Review Fix and document workflow

46. Responsible persons Manager Team Lead

47. How does it work in real world

48. Binary state Not done Will be done In progress Nearly done Done

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!

50. 7 main problems

51. No common understanding

52. No commitment

53. Unrealistic

54. Too ideal

55. Partially done tasks are accepted Done?

56. "Broken windows" principle

57. “Development” only

58. Let’s try to build Definition of Done!

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

61. Q&A Email us: mikalai.alimenkou@xpinjection.com aleksey.solntsev@xpinjection.com