Modern engineering work rarely fits neatly into a single, fixed sprint plan. As teams grow and systems move closer to GA, unpredictability becomes the norm rather than the exception. The NOS model is a simple structural change that acknowledges this reality – without adding process overhead.

NOS = Normal | Overhead | Stretch

Background

Today, each team typically creates one sprint per period (usually bi-weekly), for example:

CrewName 10/15–10/28

In practice, this model breaks down in several ways.

Key Challenges

1. Unavoidable Overhead
New work routinely appears mid-sprint – urgent customer issues, Customer alarms, SME consultations, release – driven priorities. Continuous re-prioritization is unavoidable, especially during GA phases. A rigid 15-day commitment does not reflect how work actually happens.

2. No Clear Space for Stretch Goals
We lack a clean mechanism to track opportunistic or “nice-to-have” work that teams can take on when capacity opens up.

3. Label Fatigue
Using Jira labels to distinguish planned, unplanned, and stretch work has proven cumbersome and inconsistent. Labels add cognitive overhead without solving the underlying issue.

4. Unreliable Metrics
When priorities shift mid-sprint, sprint metrics lose meaning. Planned vs. completed work, planning accuracy, and predictability all become noisy, limiting our ability to learn and improve.

Proposal: The NOS Sprint Model

For every sprint period, instead of creating one sprint, create three parallel sprints:

1. Normal Sprint

Example: CrewName 10/15–10/28

2. Overhead Sprint

Example: CrewName Overhead 10/15–10/28 or CrewName OH 10/15–10/28

3. Stretch Sprint

Example: CrewName Stretch 10/15–10/28 or CrewName SH 10/15–10/28

This is not three workflows – it’s three views of the same two-week reality.

How It Works?

✅ Normal Sprint

  • Conduct sprint planning as usual.
  • All committed, planned work goes here.
  • Capacity planning and sprint commitments are based solely on this sprint.
  • This sprint represents what the team promised to deliver to the best information available on planning day.

🔧 Overhead Sprint

  • Starts empty.
  • Captures unplanned work that arises during the sprint:
    • Urgent customer issues
    • Alarms escalated to non oncalls.
    • SME Consults
    • Release-driven interruptions
  • (Excludes formal on-call work if tracked separately.)
  • Record actual time spent on each overhead item.

This sprint reflects what the team had to handle, even if it wasn’t planned.

🚀 Stretch Sprint

  • Captures stretch or opportunistic work.
  • Represents meaningful tasks the team would like to do if capacity opens up.
  • Typically target ~25% of total capacity
    (e.g., 2–3 days in a 10-day sprint).
  • Acts as a prioritized “next-up” queue, reducing idle time and decision friction.
  • Also satisfies the ones, who always want to have plate filled, and realizes it is too much for them at the end of sprint.

Measurement & Insights

At sprint close, we can analyze work at different levels of aggregation:

ScopeWhat We Learn
Normal SprintPlanned vs. completed work; sprint predictability
Normal + StretchPlanning accuracy including opportunistic work
Normal + Stretch + OverheadTrue workload; overhead percentage per team or developer

This enables us to:

  • Quantify unplanned overhead per sprint and per developer
  • Understand how often stretch goals are completed
  • Identify systemic sources of interruption
  • Improve planning accuracy with segmented, honest data

FAQ

“We can barely manage one sprint—how will we manage three?”

A fair concern. The key point is that this is not three separate boards or ceremonies.

In daily execution:

  • We already use “All Sprints” view on the sprint board.
  • Standups continue exactly as they do today – same board, same flow.
  • This is effectively a 3-D view of the same work we currently try (and fail) to model with labels.

To reduce noise:

  • Developers use Quick Filters (by assignee) during standups.
  • Each engineer should ideally belong to only one team’s sprint set, avoiding confusion.

The net effect:
More clarity, better data, minimal additional effort.

Closing Thought

The NOS model does not attempt to eliminate unpredictability. Instead, it embraces reality, makes hidden work visible, and creates cleaner feedback loops for learning.

By separating commitment, interruption, and opportunity, we can plan better, measure more honestly, and reduce the friction teams face every sprint.

Sometimes, better process isn’t about doing more—it’s about seeing more clearly.