Out of scope needs a trigger

In the realm of project management, scope creep is a common issue faced by teams, especially those early in their careers. Two primary ways scope can be mismanaged are by either solving more than what was asked without notifying the client, or leaving out important elements without informing anyone. Both scenarios can lead to unwelcome surprises during review.

When conducting PR reviews, the key question to ask is: what's out of scope here? A comprehensive answer should consist of three elements: what was omitted, why it was left out, and when it will come back into play. A frequent oversight is neglecting the third part – the timing of reintroduction.

To illustrate, consider the design system's Uploader and Modal components left out of a portal fix. The reason behind this omission was the differing fix patterns. The reintroduction of these components would occur when a consumer requests them. Another example involves the Vitest migration where a root-level monorepo config was omitted. The justification was that only one package has tests. This component will be reintroduced when a second package starts receiving tests.

Without clearly specifying when the out-of-scope elements will be addressed, they transform into accumulating debt. However, when the timing is defined, it becomes a clear decision that any team member can undertake without needing to consult the original writer. This approach classifies scope as a decision rather than a surprise.

The question then arises: how does your team document what was left out of a project?