Although all of us speak the same language, each of us uses different meaning of words "soon”, "fine” and "done”. That’s why for one developer "I’m done” means that just a moment ago the part of the code with implemented functionality has been successfully executed, while for another developer it means that code has been committed to repository but without checking if build is green or not on continuous integration server. At the same time "done" of developer-perfectionist means totally refactored and optimized code. And only for "black swan”-developer phrase "I'm done“ means that all tests were passed, new functionality was documented on wiki and a new feature was verified by customer on the demo server. So if you want to decrease a risk of misunderstanding inside a team or between team and customer you should make agreement about common vision of “definition of done“ and then start using it on a daily basis. In order to prevent losing your time and stepping on the hidden rake during discussion of your done criteria we will share our knowledge about creating compact and most effective “definition of done“. We will talk about lifecycle of this document and about approaches that help you to add important items to it. We will discuss doneness on different levels (preplanning, user story and task development, sprint). And of course we won’t forget to tell you how to create “Definition of Done“ which will satisfy not only your team but your customer as well.

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? Start

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