Ask what the standardisation is for
The question as posed contains no problem, only a difference, and differences are not defects. So the first move is to find out what is actually going wrong, because there are three quite distinct motives behind a request like this and they lead to opposite answers.
If the motive is that joint releases keep breaking — one team's work arrives untested, integration happens late, nobody can say whether the product as a whole is releasable — then there is something real to fix and it is narrow. If the motive is that new joiners and moving engineers face two sets of conventions, that is a genuine but small cost, usually worth a shared glossary rather than a shared process. And if the motive is that somebody wants a dashboard where the two teams' numbers are comparable, then standardisation will not deliver it, because comparability requires the two teams to size work identically, which they will not, and pursuing it produces the worst outcome available: two teams following one process badly and gaming the same number.
Ask directly what decision the standardisation would improve. If nobody can name one, you have your answer.
The one thing that cannot be team-local
There is a genuine constraint here, and it is worth knowing precisely because interviewers ask it. When multiple Scrum Teams work together on the same product, they must mutually define and comply with the same Definition of Done. That is not a preference; it follows from what the Definition of Done is. It defines the state at which an increment is releasable, and two teams contributing to one release cannot hold two different notions of releasable without the release having no meaning at all. If Team A's done includes performance testing and Team B's does not, the product's quality is whichever of the two is weaker, and nobody has decided that.
Everything else on the programme manager's list is a different kind of thing. Around the shared Definition of Done, a small number of joint agreements earn their cost because a release depends on them: the interface between the two teams' work and how a change to it is communicated, where and how often integration happens, and one ordered backlog with one person accountable for the ordering if the two teams are serving the same Product Goal. Those are agreements about the seams, and they are the whole of what scaling coordination genuinely requires.
| Common by necessity | Local by default |
|---|
| Definition of Done, mutually defined for the shared increment | Sprint length and start day |
| The integration point and cadence | Board columns, work-in-progress limits, working agreements |
| The interface contract and how changes to it are announced | Estimation unit, or whether they estimate at all |
| Ordering of the shared backlog, with one accountable person | How refinement and retrospectives are run |
| Release and rollback mechanics | Ceremony times, formats and facilitators |
The distinction underneath that table is worth stating in an interview because it generalises: standardise what crosses the boundary, leave what lives inside it. A convention only needs to be shared if two teams have to interpret it identically for the product to work.
Managers tend to price standardisation at zero, and the costs are real and predictable.
The first is that improvement stops. A team that chose its own board and its own working agreements can change them next week when a retrospective identifies something; a team operating a standard has to raise a change request against a process it does not own, and it will not bother. You have traded a local feedback loop for consistency, and the local feedback loop was the mechanism by which anything got better.
The second is that ownership transfers. The moment the process is somebody else's, its failures are also somebody else's, and a team that would have fixed its own problem now escalates it. This is the most common way a well-intentioned programme office makes delivery worse, and it happens quietly over about two quarters.
The third is that the standard is set by whoever writes it rather than by what works, and it tends to encode the practices of the larger or louder team. If Team B is asked to adopt Team A's process, Team B has been told its judgement counts for less, and the cost of that is paid in every subsequent conversation.
Cadence looks obvious and mostly is not
The change people reach for first is a common Sprint length, and it is worth examining because the reasoning behind it is usually wrong. Different cadences do create real friction, but only at the join: if Team A works in one-week Sprints and Team B in three, then a dependency raised at the start of A's Sprint may wait up to three weeks, and any joint planning or review has to pick a rhythm that suits neither.
The right question is whether that friction is worth removing by aligning cadence or by removing the dependency. If the two teams need each other's work every Sprint, they are not two teams in any useful sense and the boundary is the problem. If they need each other rarely, then differing Sprint lengths cost you a handful of awkward handoffs a quarter, which is much cheaper than making a team that thrives on one-week feedback wait three.
Where alignment genuinely helps is when the two teams must plan against each other regularly or release together on a fixed rhythm. Even then, the cheaper intervention is often a common integration and release cadence with independent Sprint lengths inside it, which buys the coordination without taking the shorter loop away from the team that benefits from it.
Converge by agreement, and know when you would not
The route matters as much as the destination. Get the two teams in one room, put the shared Definition of Done on the table as the thing that must be common, and let them write it jointly — including the uncomfortable part, which is that converging on the stronger version means the weaker team's throughput drops for a while as it absorbs work it was previously deferring. Say that in advance, to the programme manager as well as the teams, because a throughput dip that was predicted is a cost and one that was not is evidence that the change failed.
Where one team's standard is genuinely weaker, converge in stages with dates rather than in one step: agree the target, agree which clauses land this quarter, and treat the remainder as visible debt with an owner. That is slower than a mandate and it is the version that survives, because the team has agreed to the thing it now has to do.
A mandate is occasionally correct, and being able to say when is what separates a considered answer from a reflexive one. Impose a standard where the cost of divergence falls on someone other than the team — security controls, audit evidence, release and rollback mechanics, anything a regulator or a customer contract fixes. In those cases the organisation has already made the decision, and pretending it is open for team discussion wastes everybody's time and produces a worse outcome than saying plainly that this part is not negotiable and here is why.
What you should refuse is standardisation whose only beneficiary is a report. Making both teams estimate in the same unit so their velocities can be compared does not make the comparison valid; it makes the invalid comparison easier to draw, and the number will be managed rather than earned within a quarter.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).