People early in their careers usually get scope wrong in one of two ways: they solve more than was asked without saying so, or they leave something out without saying so. Both become surprises in review.
In PR reviews, the question I ask most is: "what's out of scope here?"
And a good answer has three parts, not one:
- What was left out.
- Why.
- When it comes back.
The third is the one almost everyone forgets. Two examples from our design system:
- Uploader and Modal were left out of a portal fix. Why: the fix pattern is different. When it comes back: when a consumer asks for it.
- In the Vitest migration, a root-level monorepo config was left out. Why: only one package has tests. When it comes back: when a second package gets tests.
Without "when it comes back", out of scope turns into forgotten debt. With it, it becomes a decision with a trigger, one anyone on the team can pick up without asking the person who wrote it.
Named scope is a decision. Unnamed scope is a surprise.
How does your team record what was left out?
Top comments (0)