Scope Discipline

Scope Discipline means that we have the discipline to only make changes within our chosen scope. The goal is to get from one working state to the next as directly as possible. Making changes outside the current scope increases the risk of breaking something, makes it harder to find the cause when something breaks, and more difficult to understand the change in general. It also delays our current goal, which delays feedback and potential value.

How often has it happened to you that you ended up with many parts of your feature "almost done" but being far from an integrable state? This is a common problem, and it gets in the way of practices like CI/CD: If the application is not in a compilable, working (tests passing), and integrable state for extended periods of time, it causes longer feedback cycles, higher risk of bugs, and more/larger merge conflicts.

Scope discipline requires us to (know the scope of the next commit) [know-your-next-commit.md] in the first place, so the habits complement each other.

Example: Staying in scope

While working on a new feature, you see a messy piece of code. Instead of starting to refactor it, you ask yourself: Is this in the scope of my current change? Is it in the part of the code (or very close by) that I need to change anyway? If yes, you make the change. If no, you take note and change it afterwards in a separate commit.