Understanding and Apply Scrum [P7]: Done - Getting started with a DoD Flashcards
What does the DoD create?
transparency by providing everyone a shared understanding of what work was completed as part of the Increment
What happens if a product backlog item (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
How does the dev team create a DoD from a high level POV?
- needs to decide what Done means within the organizational context and the product domain
- need to sit down and create a list of things that must be true for every Increment of software that they deliver
Why do we need a DoD?
- So we know what working software means
- thus know that it is shippable and meets the agreed acceptable standard
- need it for predictable delivery
- PO can’t reject sprint backlog item unless they have a reference of what done means
What are some core characteristics of a DoD?
- A short, measurable checklist
- Mirrors shippable
- No further work
Explain the “A short, measurable checklist” character of a DoD?
try and have things on your DoD that can be measured, that you can test the outcome, preferably in an automated fashion
Explain the “Mirrors shippable” character of a DoD?
- While you might not have shipped the product (although recommended!), you should have that choice
- PO should be able to say at the sprint review, awesome let’s ship
Explain the “No further work” character of a DoD?
- no more work required from dev team to ship product to production
- any additional work means YOU ARE NOT DONE and it takes away from the PO capacity for the next iteration
- ideally, you have a fully automated process for delivering software and use staggered iterations for delivery
Tips for writing you first DoD?
run a workshop with dev team, PO and relevant stakeholders (and any people who get stage gates after devs are Done)
Suggestions for things to put on DoD?
- Increment Passes SonarCube checks with no Critical errors
- Increment’s Code Coverage stays the same or gets higher
- Increment meets agreed engineering standards e.g. naming conventions, tests, wiki for list
- Acceptance Criteria for Increment pass - reqs met
- Acceptance Tests for Increment are Automated
- Security Checks Pass on Increment
- Increment meets agreed UX standards
- Increment meets agreed Architectural Guidelines
Elaborate on “Increment Passes SonarCube checks with no Critical errors”
You will be increasing over time, so maybe you need to say “Code Passes SonarCube checks with no more than 50 Critical errors” then work on it over time.
Elaborate on “Increment’s Code Coverage stays the same or gets higher”
Looking at a specific measure, like 90%, of code coverage is a read hearing and tells you nothing of code quality. However, it might be advantageous to monitor and measure for adverse change in code coverage, and always advocate for TDD practices
Elaborate on “Increment meets agreed engineering standards e.g. naming conventions, tests, wiki for list”
You should decide rules for naming of methods, tests, variables and everything in-between. Start small and add over time. Link to your agreed standards on a Wiki and continuously improve and expand your rules. Automate if possible.
Elaborate on “Acceptance Criteria for Increment pass - reqs met”
Making sure you at least meet the prescribed criteria is a laudable goal and automated via ATDD where possible
Elaborate on “Acceptance Tests for Increment are Automated”
Make sure that you automate all of your tests. If you think something will break, then you should have a test for it.
