The court-payment team demos every story against mocked payment-gateway and docket integrations, then marks the increment Done. ART System Demo later fails on the real interfaces. What should the SM/TC insist on?
Select an answer to reveal the explanation.
Short Explanation
A mock court-payment demo is a cardboard courthouse: it looks like a building until someone tries the door. Done means the increment actually talks to the gateway and the docket. Fake green reviews just hide the integration jam until System Demo.
Full Explanation
Done must mean integrated, working increments on real interfaces—not mocks that only please Iteration Review. The court-payment team that demos every story against mocked payment-gateway and docket integrations then fails ART System Demo on real interfaces is shipping fake flow. The Scrum Master/Team Coach should insist that Done includes real interface validation appropriate to the increment so ART-level integration is honest for civic payments.
Keeping mocks as the Definition of Done so Iteration Review stays green fails by concept: green local demos with red ART demos hide integration risk. Skipping ART-level integration and letting each team demo only its own mocks fails by concept by abandoning the ART’s purpose of a working system increment. Adding a quarterly real-integration week after three PIs of mocked demos fails by concept: it batches integration risk into rare painful events.
Exam caveat: SAFe System Demo and team Done expectations require a working, integrated system increment; mocks are development aids, not a substitute for Done on interface-critical court-payment flows. Some stubbing during development remains fine if integration evidence lands before calling the increment Done.
Operational check: update DoD to require verified integration with the real or ART-provided test payment/docket interfaces before Done, demo those integrations at team and System Demo, and track System Demo failures caused by mock-only readiness to zero.