What this template is for
Feature flags are the most powerful safety tool in modern delivery, and the most commonly abused. Done well, they let you decouple deploy from release and roll back without re-deploying. Done badly, they become a tangle of long-lived booleans that nobody dares delete.
This template encodes the discipline of a good rollout: explicit stages, explicit success criteria at each stage, an explicit kill switch, and an explicit removal date.
When to use it
Use this template whenever you are enabling a non-trivial feature for real users. Trivial copy or config flags do not need a full rollout plan. Use the template for:
- Any change that touches a customer-visible flow (checkout, signup, search)
- Any change with measurable business metrics tied to it
- Any change where rollback by re-deploy would be slow or risky
- Any change that pairs with an A/B test or experiment
Sub-task breakdown
The sub-tasks above turn a rollout from a slack thread into a controlled progression. The last sub-task - ‘schedule flag removal once stable for 30 days’ - is the one that most teams forget; STM Issue Templates is particularly useful here because that removal sub-task gets created automatically and shows up in the ticket queue 30 days from now whether anyone remembers it or not.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Rollout: new-checkout-flow flag to 100% | Yes |
Flag Name (custom) | new-checkout-flow | Yes |
Flag Provider (custom) | LaunchDarkly / Unleash / Statsig / internal | Yes |
Current Audience (custom) | internal-only | Yes |
Target Audience (custom) | 100% authenticated US users | Yes |
Rollout Stages (custom) | 1% / 10% / 50% / 100% with 24h soak each | Yes |
Success Criteria (custom) | Conversion >= baseline; error rate < 0.5% | Yes |
Kill Switch Plan (custom) | Flip flag to 0% in LD; no deploy needed | Yes |
Monitoring Dashboard | https://grafana.example.com/d/checkout | No |
Owner | @alex.chen | No |
Linked Epic | PROJ-902 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Confirm the flag is wired up in code with a safe default (off)
- Enable for internal users; verify happy path and key metrics
- Ramp to 1% and soak for 24h; confirm no regressions
- Ramp to 10%; review dashboards against success criteria
- Ramp to 50%; review dashboards and customer-support signal
- Ramp to 100% and announce to stakeholders
- Schedule flag removal once stable for 30 days
Common questions
What is a feature flag rollout plan?
It is the written plan for moving a feature from off to fully on - which audiences, in what stages, with what success criteria at each stage, and what triggers a rollback. Without a written plan, feature flags become permanent dark debt; with one, they are a controlled progressive delivery.
How do you decide rollout stages for a feature flag?
Start at the smallest audience that produces a useful signal - usually internal users, then 1%, 10%, 50%, 100%. Each stage should soak long enough to detect regressions across at least one full business cycle (24h for consumer traffic, a full sprint for B2B). Skipping stages is fine for low-risk flags; document why on the ticket.
Should the kill-switch plan be a required field?
Yes. The whole point of a feature flag is reversibility, and 'flip the flag back' is only safe if you have written down exactly which flag, in which provider, and what to expect after the flip. A required Kill Switch Plan field forces the owner to confirm reversibility before the first ramp.
How do you avoid feature flags becoming permanent?
Schedule flag removal as the last sub-task on the rollout ticket - usually 30 days after 100%. [STM Issue Templates](/stm/) can auto-create that removal sub-task on every rollout ticket so cleanup is part of the workflow, not an afterthought. Stale flags are how rollout systems turn into config-debt landfills.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →