Sprint & Release Calendar Language

Feature freeze — what it means for the team

Feature freeze is a milestone before a release where the scope is locked:

• Allowed after feature freeze: bug fixes, test improvements, documentation, performance fixes, UI polish
• Not allowed after feature freeze: new features, significant new behaviour, changes to unrelated code

Why feature freeze matters:

• Gives QA a stable target — the feature set doesn't change while they test
• Reduces risk — late feature additions are a common source of release regressions
• Signals to stakeholders — "what you see now is what ships"

Feature freeze vs. code freeze:

• Feature freeze: scope locked — no new features
• Code freeze: code locked — no new merges at all, typically 24–48 hours before release

Vocabulary:

• "We're in feature freeze — this change will have to wait for the next release."
• "The PR is post-feature-freeze — it needs explicit release manager approval."
• "Feature freeze gives QA a stable build to test against."

Out-of-window deployment — the correct process

Deployment windows exist to:

• Ensure on-call engineers are available to respond to post-deployment issues
• Align deployments with low-traffic periods
• Prevent surprise changes outside agreed change management processes

For critical fixes that can't wait: Most organisations have an emergency change process (sometimes called an expedited change or break-glass procedure):

1. Document the issue and the risk of waiting
2. Get approval from the on-call lead, engineering manager, or change advisory board (CAB)
3. Increase monitoring coverage during and after the deployment
4. Document the out-of-window deployment in the change log

Why not just deploying (A) is a problem: Unauthorized deployments bypass change management, can surprise on-call engineers, and create untracked changes in production.

Vocabulary:

• "This is an emergency change — I'm requesting an out-of-window deployment."
• "Deployment window closes at 12:00 UTC — this will need to wait until Thursday or go through the emergency process."
• "All out-of-window deployments must be approved by the on-call lead."

Holiday change freeze — scope and exceptions

A holiday change freeze restricts changes to production systems during a period of reduced team availability:

• Reason: holiday periods have reduced on-call staffing. A broken deployment with 30% of the team out of office is harder to recover from.
• Duration: 2026-12-20 to 2027-01-03 = approximately 2 weeks
• Permitted: P0 critical production fixes (data loss, security breach, complete outage)
• Not permitted: feature releases, performance improvements, refactoring, P1/P2 bug fixes during this window

P0 exception process: Even P0 fixes during a change freeze require:

• Documentation of the incident and risk
• Approval from the on-call engineering lead
• Increased observation period post-deployment

Vocabulary:

• "We're in change freeze — this has to wait until after January 3rd."
• "This is P0 severity — I'm requesting an exception to the change freeze."
• "The change freeze window runs from [date] to [date] UTC."

Bi-weekly sprint cadence — clarifying the ambiguity

"Bi-weekly" is genuinely ambiguous in English:

• In most tech contexts: every two weeks (fortnightly)
• Technically: can mean either "twice a week" OR "every two weeks"

The tech industry standard for sprints: 2-week (fortnightly) sprints are the most common Scrum cadence. The response clarifies exactly how the 2-week cycle works.

To avoid ambiguity in professional writing:

• Prefer "fortnightly" (unambiguous = every two weeks)
• Or write "2-week sprints" — always clear
• Avoid "bi-weekly" in scheduling contexts unless defined

Sprint calendar vocabulary:

• "Our sprint cadence is [1-week / 2-week / 4-week]."
• "Sprint N starts on [date] and ends on [date]."
• "The sprint review is on the last Friday of each sprint."
• "We're mid-sprint — the next planning session is in [N] days."

Converting vague timelines to specific dates

"Sometime next month" is problematic for planning:

• Teams can't prioritise work against a vague target
• Stakeholders may interpret "next month" differently (start? end?)
• If communicated externally, customers have undefined expectations

The professional response:

1. Acknowledges the intent to ship next month
2. Asks to convert to a specific date
3. Offers concrete sprint-based dates the developer can actually commit to
4. Flags the external communication risk — vague dates communicated externally become implicit promises

Good calendar commitment vocabulary:

• "We're targeting [specific date] for the production release."
• "The release candidate will be available for QA by [date]."
• "We can commit to [date] if [dependency] is resolved by [earlier date]."
• "This is a soft target — I'll flag if the timeline changes before [date]."