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 :

...