Feature Flags and Scrum: Enabling Continuous Delivery

One of the tensions in Scrum is the gap between "done" as the team defines it and "done" as the business experiences it. A feature can be code-complete, tested, and accepted by the Product Owner at the end of a Sprint -- and still not be available to users for weeks, because a release window has not opened, because other features are not ready, or because the business wants to co-ordinate the rollout with a marketing campaign.

Feature flags -- also called feature toggles -- resolve this tension by decoupling deployment from release. Code is merged to the main branch and deployed to production, but a configuration switch determines whether any given user can see or use the feature. The feature is in production; it is simply not yet activated for anyone. When the business is ready, the flag is flipped. No deployment needed. No code change required.

What Feature Flags Are

A feature flag is a conditional branch in code that checks a configuration value before executing a code path. In the simplest form, it is an if-statement: if the flag is on, execute the new code path; if the flag is off, execute the old code path (or nothing). The configuration value can be stored in a database, a dedicated feature flag service, environment variables, or even a configuration file -- the key is that it can be changed without a code deployment.

This simple mechanism enables several powerful patterns. A feature can be deployed to production and activated only for internal testers or a small percentage of users before a full rollout. If problems emerge, the flag is turned off instantly -- a far faster rollback than reverting a deployment. A feature can be held in production for weeks or months while business conditions or regulatory approvals are finalised, then released at a specific moment with no engineering involvement.

Types of Feature Flags

1. Release flags. The most common type. Used to hide incomplete or not-yet-launched features from users while code is deployed continuously. Release flags are intended to be short-lived -- they are created when a feature begins development and removed once the feature is fully launched. Leaving release flags in code indefinitely is a form of technical debt.

2. Experiment flags. Used for A/B testing and multivariate experiments. Different user segments see different versions of a feature; the flag controls which segment gets which version. Experiment flags feed into analytics: which version performs better on the target metric? They are also temporary -- removed once the experiment concludes and a winning variant is selected.

3. Ops flags. Used to control operational behaviour of a system at runtime -- throttling a feature under load, enabling a circuit breaker, switching between two backend implementations. Unlike release flags, ops flags may be long-lived and represent permanent operational controls rather than temporary deployment gates.

4. Permission flags. Used to control which users or accounts can access a feature -- based on subscription tier, geographic region, user role, or explicit permission grants. These are often permanent configuration, managed through account management systems rather than developer flag management tools.

The Technical Discipline Feature Flags Require

Feature flags are not free. Every flag adds a conditional branch to the code, and every conditional branch adds complexity. An accumulation of untended flags -- flags that were created for features that launched months ago, flags for experiments that concluded, flags for rollouts that completed -- is sometimes called a flag graveyard, and it creates genuine maintenance and testing burden.

Good flag hygiene requires treating flag removal as part of the Definition of Done for feature work. When a feature is fully launched and stable, the flag should be removed: the new code path becomes the only code path, and the old path is deleted. This cleanup is engineering work that needs to be planned and prioritised, not treated as optional housekeeping.

Testing discipline is equally important. Every flag creates two states that must be tested: the flag-on state and the flag-off state. A feature that works correctly when its flag is on may break something in the flag-off code path, or vice versa. Teams adopting flags need to build this into their test strategies -- both automated test coverage and exploratory testing practices.

How Feature Flags Change Sprint Planning and Definition of Done

Feature flags shift the conversation in Sprint Planning. Without flags, 'done' often implicitly means 'deployed and visible to users.' With flags, a team can commit to having a feature deployed and flag-protected by Sprint end, with business activation to follow when conditions are met. This gives the Product Owner more flexibility: Sprint commitments are about code being ready, not about business launch timing.

The Definition of Done needs to be updated to reflect flags explicitly. A robust DoD for flagged work typically includes: code merged to main, flag implementation tested in both states, flag configuration accessible to the right stakeholders (not requiring a developer to flip it), monitoring in place to detect problems when the flag is activated, and a flag removal ticket created to track the cleanup work.

The most significant change is cultural: continuous delivery becomes genuinely continuous. Teams stop treating end-of-Sprint as a deployment event and start treating deployment as a routine engineering activity that happens multiple times per week or even per day. The business release -- the moment users see the feature -- becomes a separate, business-timed decision rather than an engineering-driven event.

XNM Consulting helps organisations build mature agile and continuous delivery practices, including the technical and governance frameworks that make feature flags safe and effective.