The document discusses defining what "done" means for software development work. It argues that agreeing on a definition of done provides clarity for estimating work, focusing efforts, and knowing when work is ready to deliver. If done is not clearly defined, work can accumulate without notice and stakeholders may be confused. Done should define when work is potentially shippable. The team should define done, with input from the product owner and stakeholders. The definition can evolve over time as the team's capabilities change. Examples of done criteria include code passing tests, being deployable, and meeting acceptance criteria.

1. DEFININGDONE

3. Not sure about if you have finished working on a feature so it can be delivered?Let’s talk about it…Ever been in a similar situation during a project?

4. WHAT «DONE» MEANS?

5. The chicken (or pig) has stopped struggling. Usually, it has stopped bleeding as wellThere is a pleasant smell coming out the kitchenYou’ve taken the meal out of the oven and it’s ready to be servedDone for cooking

6. Done for painting a roomThe room has a uniform, good looking color (maybe different than before)There are no spotsYour clothes don’t change its color after leaning on a wall

7. Done for Bart & LisaA reasonable amount of time has passed since departureThe engine of the car has been stoppedWe’re parked next to the funfair

8. If Bart and Lisa had thought about that beforehand, maybe they wouldn’t have bothered Homer. Is it the same if we are building software?Can we think about some criteria that determine if we have finished building any increment for our system?What can we learn from this?

9. WHY IS IT GOOD TO AGREE ON WHAT “DONE” MEANS?

10. Why?The team has a clearer, common idea about if anything is ready to be delivered

11. Why?It is easier to be focused on what to do, and on building value

12. Why?It provides a point of reference for estimations and planning

13. Why?Stakeholders know what to expect when they receive a new version

14. Why?It reduces the risk of accumulating partially finished things

15. WHAT HAPPENS IF “DONE” IS UNCLEAR?

16. Whathappensifit’sunclear?It is difficult to estimate our velocity/lead time/date of delivery

17. Whathappensifit’sunclear?Stakeholders can get confused about what are they receiving

18. Whathappensifit’sunclear?Undone work/technical debt can accumulate dramatically without even noticing; uncertainty grows

19. WHAT IS “DONE” FOR SOFTWARE?

20. Done should define when any piece of what we are building is "potentially shippable"If customer decides to release it, it should be possible to do it without investing much (or any) workDone = Shippable

21. The Definition of Done is a simple, auditable checklist that belongs to the teamIt can be influenced by the environment: the organization, specific characteristics of the product, circumstances of the release…It is different across teams and organizationsIt reflects the team’s capabilities at any momentIt is used as a filter when deciding what is ready to be deliveredIt is a key component in any projectBeing more specific…

22. The code compiles Tests exists and are passingApplication is deployed in an environment suitable for the customer to check itAcceptance criteria is met (it is working as expected)(Very) simple example

23. WHO DEFINES DONE?

24. The team should be the ones having the last wordProduct Owner should understand it and agree on its contentStakeholders understand it and agree on its content (on their own terms)Theteamdoes!

25. WHEN IS “DONE” DEFINED?

26. It has to be agreed upon before starting to deal with any workThe list is revised when needed, and updated if necessaryMaybe you will stick with the same list for the entire projectMaybe you will make some changes at certain points to incorporate new skills or capabilitiesMaybe you will remove things that no longer make senseMaybe you’ll change it only for a particular release or iterationAnytime… butalwaysbeforebeginning

27. HOW CAN I MAKE UP THE LIST?

28. Guideline

29. Don’t ship demos or prototypesAssure that the application does anything that it’s supposed to do (functional validation is very important)The customer should be able to begin using whatever has been built immediatelyDon’t sacrifice internal quality or accumulate technical debtYou’renot in analmightyteam!Start simple and evolve itBrainstorm, having in mind…

30. What if I’m asked to ship even knowing that “done” has not been met?

31. Make it explicitKeep track of any undone workFix it as soon as possible. At the very latest, before shippingTry toavoidit!Butifthereis no way…

32. REVISING THE EXAMPLES…

33. The chicken (or pig) has stopped struggling. Usually, it has stopped bleeding as wellThere is a pleasant smell coming out the kitchenYou’ve taken the meal out of the oven and it’s ready to be servedDone for cooking

34. The kitchen is clean and tidy againYou’vepreparedthreecoursesIt tastes good, and guestscongratulateyouforthedinnerDone for cooking

35. Done for painting a roomThe room has a uniform, good looking color (maybe different than before)There are no spotsYour clothes don’t change its color after leaning on a wall

36. But also…Thereisnot a buckethalffilledwithpaint in thewayThefurniture has returnedtoits placeYoudon’thavepaint spots alloveryou

37. Designed Coded and refactoredUnit testedBuild automatedFunctional testedIntegration testedUser acceptance testedRegression testedPerformance testedSecurity testedPeer reviewedMerged to main branch in version controlBacklog updatedX% code coverage achievedPackaged, or installer generatedDeployment automatedUser manual updated…What about software?

38. ALM Team Lead at PlainConceptsProfessional ScrumDeveloperTrainer, PSM I, CSMjlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria@jlsoriatJOSE LUIS SORIAThanks!!!