Definition of Done

• Commitment of the Increment
• Created by:
  • If the DoD for is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If not organizational standard, the Scrum Team must create a DoD appropriate for the product
  • multiple Scrum Teams working together on a product, they must mutually define & comply with the same DoD
• MAIN:
  • creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment
  • helps to forecast how many PBIs can be taken into a Sprint
  • knowing when you are “Done” frames the work which must be undertaken in order to get there
• NOTE:
  • Working Software is not specific to a PBI; it’s applied regardless of PBI to the entire delivery. Not just for each PBI
  • Your Product Owner can’t reject a Backlog Item, only whether the Increment is working or not
• Why is "Done" so important?
  • Well, incomplete work has a nasty habit of mounting up, and without visibility of how much effort truly remains, the deficit can quickly get out of hand
  • The tyranny of work which is nearly done, but not really done, can put a team in servitude to technical debt
  • obliged to repay the “deficit for release” at compounding rates of interest
  • Eventually the expense of fixing things, of repaying the debt, may exceed the value to be had from the next product increment
• If a PBI does not meet the DoD, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration
• If you can’t ship working software at least every 30 days then by its very definition, you are not yet doing Scrum
• a list of things that must be true for every Increment of software that they deliver
• DoD is an understanding of what makes an increment truly releasable - and therefore genuinely “Done”
• My first DoD
  • Before you cut a single line of code, you need to decide what done means for your product and your company
  • You need to start somewhere: Your DoD does not just magically appear, and your software does not magically comply: should organically grow, you need to create the seed that you can build on
  • Whatever DoD you come up with it is unlikely that your entire Product currently meets the criteria. You are not yet doing Scrum. Before you start Sprinting, you need to focus on making sure that your current Increment meets your new DoD: Create a usable increment that meets your DoD and then start sprinting
  • Tips:
    • As a Scrum Master, coach your team to continuously expand their Definition of Done. More simply speaking, help the team to reduce the amount of work left to do after they consider it done (e.g. testing, quality assurance, release, documentation)
    • With your team and within your organization, reflect on the amount of work that needs to done after a team considers an increment “done” (e.q. QA, deployment). Help both the organization and the team to change processes and practices to decrease this amount of ‘undone’ work
• It’s super important that quality is always increasing, a Kaizen moment at the Sprint Retrospective
• If your Developers finds that something is missing from the DoD halfway through the Sprint, then they should go ahead and add it, making sure that they are not endangering the Sprint Goal
• Scrumble: stop Sprinting because of poor quality: stop adding new features and create a usable increment before you continue Sprinting and adding new features
• Some characteristics
  • Short, measurable checklist
  • Shippable, usable, releasable
  • No further work to be shipped to production
• Examples
  • Increment Passes SonarCube checks with no Critical errors
  • Increment’s Code Coverage stays the same or gets higher
  • Increment meets agreed engineering standards
  • Acceptance Criteria for Increment pass
  • Acceptance Tests for Increment are Automated
  • Security Checks Pass on Increment
  • Increment meets agreed UX standards
  • Increment meets agreed Architectural Guidelines
• More Examples
  • Environments are prepared for release
  • Handover to support is complete
  • Review Ready
  • Code Complete
  • Test Complete
• DEFICIT FOR RELEASE
  • "Done" criteria which are needed to effect a release, but which cannot yet be observed, constitute a deficit. They should be enumerated here (e.g. by moving them out of the Definition of Done)
• Definition of Done Should include a Definition of Undo(ne)
  • Continuous Integration (CI):
    • Get code integrated
    • when you finished your work you committed that work into the main development branch, with everyone else and it was integrated, deployed to some magical environment and then tested
  • Continuous Delivery:
    • Get code in production
    • applied the ideas of CI on a much grander scale
  • CD and Data capture/analysis
    • If the goal is to release software or actually answer questions or learn something
  • DoUND; Rollback