Understanding and Apply Scrum [P7]: Done - Walking through a Definition of Done Flashcards
Explain “Scrum begins with Done”
- must define the end before we can start
- knowing when you are Done frames the work which must be undertaken in order to get there
Why does an understanding of what makes in increment truly releasable and therefore genuinely Done provide?
transparency over the work a Dev team plans to do, and the tasks it brings into progress
Why is Done so important? I.e. what happens without having a DoD?
- 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
- TD - The tyranny of work which isnearly done, but notreally done, can put a team in servitude to technical debt —> always chasing to pay off TD and its compounding interest
Explain the example of a DoD item: “1. Environments are prepared for release”
- check no unintegrated work in progress has been left in any development or staging environment
- check that CI framework is verified and working, including regression tests and automated code reviews
- build engine should be schedule a build on check-in (also hourly/nightly)
- check that all test date used for validation has been validated
Explain the example of a DoD item: “2. Handover to support is complete”
- All design models and specifications, including user stories and tests, must be accepted by support personnel who will maintain the increment henceforth
- support must be satisfied that they are in competent control of the supporting environment
Explain the example of a DoD item: “3. Review Ready”
- sprint metrics available - including burn down and burn up charts
- uncompleted user stories re-estimated and returned to PB
Explain the example of a DoD item: “4. Code Complete”
- Resolved TODO annotations
- source code comments at satisfactory level
- source code refactored - understandable, maintainable and promotes future change
- tests cases for all features + clear naming convention for req tracing + all pass
- known agreed code coverage level + met
- pair reviews done
- merged with main branch
- automatic deployment into elevated envs verified
Explain the example of a DoD item: “5. Test Complete”
- functional testing done - automated and manual
- test report generated
- outstanding defects elicited and resolved or accept by team as not being harmful to the release
- regression completed and previous working functionality still good
- all functionality works on all required platforms
What is meant by a deficit for release?
- Done criteria which are needed to effect a release, but which cannot yet be observed
- create a list for this — move them out of DoD
Is the DoD influenced by the org? Why
Yes
need to combine org’s DoD with PO and Dev’s DoD
- e.g. non-functional reqs - docs, scalability
⇒ minimize waste! - on the same page regarding org wide things