Trunk-Based Development: The Engineering Practice That Makes Scrum Work
Scrum teams commit to delivering working software at the end of every sprint. That commitment is only credible if the engineering practices that underpin the team's ability to integrate and release on demand are actually in place. In many Scrum teams, they are not. Teams work in long-lived feature branches — branches that diverge from the main codebase for days or weeks at a time — then face a painful integration event at the end of the sprint when everyone's work is merged simultaneously. The integration cost is high, the feedback is delayed, and the promise of continuous delivery remains theoretical rather than operational. Trunk-based development is the engineering practice that closes this gap.
The problem with long-lived feature branches
A feature branch is a copy of the codebase that diverges from the main line when a developer begins work and is intended to be merged back when the work is complete. In principle, this isolates work in progress from the stable main codebase. In practice, the longer a branch lives, the more it diverges. Every commit to main by other developers creates a divergence that will need to be reconciled at merge time. A branch that has been active for two weeks may need to reconcile hundreds of changes it has not seen before merging. This creates several forms of waste. Merge conflicts consume developer time on non-value-adding reconciliation. Integration surprises — features that work in isolation but break when integrated with other in-flight work — cause rework and delays. And delayed feedback means that design or architectural problems in a feature are not visible to the team until long after the work was done, when the cost of changing it is highest.
What trunk-based development means in practice
Commit to main at least once a day. The central discipline of trunk-based development is that every developer integrates their work with the main branch at least once every twenty-four hours. This means that the longest any piece of work can diverge from main before reconciliation is one day. Merge conflicts are small and frequent rather than large and occasional. Integration surprises are caught within hours rather than within weeks.
Use short-lived branches of no more than two days. Some teams working in trunk-based development use no branches at all, committing directly to main. Others use very short-lived branches — typically limited to one or two days of life — as a unit of work that is completed and merged before beginning the next. The two-day limit is a heuristic, not a rule: the goal is to prevent the accumulation of divergence that makes integration expensive. A branch that cannot be completed and merged in two days is usually a signal that the work needs to be broken down further.
Use feature flags rather than branches to hide incomplete work. The most common objection to trunk-based development is: "We cannot merge incomplete work to main — it will break production." Feature flags solve this. A feature flag is a configuration switch that controls whether a piece of functionality is active in production. Incomplete features are merged to main behind a flag that is off in production. The code is integrated and tested in the main codebase but not exposed to end users until the team is ready to turn the flag on. This separates deployment from release: the code can be in production without being visible to users.
Technical prerequisites
Trunk-based development requires an engineering environment that makes frequent integration safe. Fast automated tests are the most important prerequisite: if a build takes forty-five minutes, developers will not integrate frequently, because the feedback cycle is too slow. A trunk-based team needs a test suite that provides meaningful coverage and runs in minutes, not hours. Feature flag infrastructure — a system for managing, deploying, and auditing flags — is the second prerequisite. Ad hoc feature flags managed in code become technical debt quickly; a proper feature flag management system allows flags to be created, managed, and retired cleanly. Finally, small commit culture — the habit of breaking work into small, independently deployable increments — is a prerequisite that is more cultural than technical but is no less important for that.
Common objections and answers
"We will have merge conflicts all the time." With trunk-based development, you will have small, frequent conflicts rather than large, infrequent ones. Small conflicts are faster to resolve and less likely to introduce bugs than large conflicts resolved under time pressure.
"Our test coverage is not good enough to merge to main safely." This is an accurate diagnosis that points to the real problem: insufficient automated test coverage. The solution is to invest in testing, not to maintain long-lived branches as a substitute.
"Feature flags add complexity." They do — and that complexity is lower than the complexity of managing long-lived branches, resolving large merge conflicts, and coordinating integration events. Managed properly, feature flags simplify the relationship between deployment and release.
"Our teams are not ready." Teams that have not worked in trunk-based development will need coaching and a transition period. The transition is not instant, but the teams that make it consistently report better integration experiences, less rework, and more confidence in their releases.
If your Scrum teams are struggling with integration, rework at sprint end, or the gap between ceremony and delivery, XNM's program and project delivery practice can help you assess your engineering practices and build the technical foundation that makes agile delivery credible.