Twenty-Two Done Items and a Contractual Release Date
A B2B SaaS provider has one Scrum Team of seven developers plus a contracted QA vendor that tests the billing module. In each of the last four two-week Sprints, roughly 30% of the committed Product Backlog items rolled into the following Sprint. Twenty-two items currently sit in the 'Done' column; nine of them were merged to main but never went through integration testing, and the vendor's component has never been part of the team's Definition of Done. A customer contract fixes a release date three weeks away with a defined scope of twenty-seven items. The Product Owner describes the nine items as 'basically done, it's just testing' and asks whether to include them so the contracted scope is met. The engineering director has offered to sign off on skipping integration testing 'this once' to protect the customer relationship.
1. Should the Product Owner include the nine untested items in the release? Reason through the decision rather than giving a rule.
Read the worked answer
The starting point is what 'Done' means here. The Definition of Done is the team's shared commitment about what completed means, and the Increment is by definition the sum of items meeting it. Nine items that have never been integration tested do not meet it. Calling them Done does not make them Done; it makes the artifact lie, and everyone downstream - support, sales, the customer - plans against a fiction.
The release itself is a business decision that belongs to the Product Owner, and releasing known-untested software is a risk decision, not a labelling decision. The legitimate options are: ship only the items that meet the Definition of Done and renegotiate scope; move the date; or deliberately release a subset behind a feature flag as a limited pilot, with the residual risk written down and accepted by the person accountable for it. What is not acceptable is relabelling the nine items to protect a scope count, or having a director 'sign off' in place of the team's quality criteria - that transfers accountability away from the people who understand the risk.
A defensible answer names the risk, names who accepts it, and keeps the Definition of Done honest either way.
2. What should be done about the split Definition of Done, the vendor's untested component, and the persistent 30% rollover?
Read the worked answer
These three symptoms share one root: the team is committing to work it cannot finish to its own standard, and part of the product sits outside that standard entirely. Since the team produces a single Increment, there should be one Definition of Done for it, agreed by the Scrum Team, covering everything that ships - including the vendor's billing component. The Product Owner may add stricter criteria by agreement; the organisation may impose a minimum; but the team owns the content, and 'the vendor's part is different' is not a quality argument.
For the rollover, the fix is at Sprint Planning and in the size of items: only pull work that can realistically reach Done within the Sprint, prefer fewer and smaller items, and let the Sprint Goal rather than a headcount of tickets define the commitment. Enforce the Definition of Done at the end of every Sprint - anything not meeting it returns to the Product Backlog transparently, which will look worse for one or two Sprints and then stabilise.
Concretely, before the release: add integration testing to the shared Definition of Done, create backlog items to bring the nine items to Done, re-forecast the contracted scope from that honest baseline, and have the Product Owner renegotiate scope or date with the customer using the new forecast.