One Job at a Time: How the Three-Function Rule Kills Scope Creep Before It Starts

Every engineer knows the feeling. A ticket comes in for a small feature — maybe a new filter on a dashboard, or a minor change to an API response. Simple enough. But then someone mentions that while you're in there, you might as well refactor that old helper. And then someone else points out a related edge case. And before you know it, a two-day task has ballooned into a three-sprint saga with four engineers in the PR thread arguing about naming conventions.

That's scope creep. And it's not a planning failure — it's a scoping failure. The fix isn't a better Jira board. It's a different way of thinking about what a unit of work actually is.

Enter the Three-Function Rule.

What the Rule Actually Says

The Three-Function Rule is straightforward: when you're defining a new feature or task, you should be able to describe it in three discrete functions — no more. Each function does exactly one thing, can be tested independently, and has a clear input/output contract. If you can't break the work into three (or fewer) testable units, the scope is too large and needs to be split.

This isn't about literal function count in your codebase. It's a forcing function — a mental constraint that makes you articulate what done actually looks like before you write a single line of code. Think of it like a compression algorithm for requirements: if the feature doesn't compress cleanly into a small number of atomic operations, you haven't understood it well enough yet.

The rule borrows conceptually from the Unix philosophy — do one thing, do it well — but applies it at the planning layer rather than the architecture layer. The goal is to catch complexity before it compounds.

Why Teams Skip This Step (And Pay for It Later)

Most teams don't lack process. They lack early process. Scope decisions get deferred to the moment someone opens a new file, which is exactly the wrong time to be making them. By then, you're already context-loaded, you've got an opinion about how it should work, and cutting scope feels like going backward.

There's also a cultural pressure at play. In a lot of engineering orgs — especially fast-moving startups — there's an implicit reward for doing more. Shipping a feature plus a refactor plus a fix feels like a win. And sometimes it is. But more often, it's the origin story for a PR that nobody wants to review, a merge conflict that eats a Friday afternoon, and a QA cycle that catches three regressions nobody anticipated.

The Three-Function Rule creates a natural checkpoint before any of that happens. It's not bureaucracy — it's a conversation. What are we actually building? What does it take in? What does it put out? What breaks if it fails?

How to Apply It in Practice

Let's say your team is adding a coupon code field to a checkout flow. Sounds simple. Here's how you'd apply the rule:

Function 1: Validate the coupon code against the database and return a discount object or an error state.

Function 2: Apply the discount object to the current cart total and return an updated pricing summary.

Function 3: Render the updated pricing summary in the UI with appropriate success/error messaging.

Three functions. Three testable units. Each one has clear boundaries, can be stubbed in tests, and can be reviewed independently. If someone suggests that you also rebuild the promo code management admin panel while you're at it — that's a fourth function, which means it's a separate ticket.

This sounds almost too simple, but the discipline of writing it out forces prioritization decisions that usually get made implicitly (and badly) during implementation.

The Velocity Paradox

Here's the counterintuitive part: limiting scope actually makes you faster. Not in a "move fast and break things" way, but in a sustainable, compounding way.

When every unit of work is small and well-defined, PRs are easier to review. Tests are easier to write. Bugs are easier to isolate. Rollbacks are less terrifying. And the feedback loop between shipping and learning gets dramatically shorter — which means your next feature gets built on better information than your last one.

Teams that practice this kind of scope discipline tend to ship more frequently, not less. They're not spending two weeks on a feature that turned into a platform. They're shipping the filter, learning how users interact with it, and then deciding whether the platform is even worth building.

It's the Build. Ship. Repeat. loop in its purest form. Small bets, fast feedback, informed next steps.

Making It Stick Across Your Team

The hardest part of the Three-Function Rule isn't understanding it — it's getting consistent buy-in, especially from stakeholders who equate feature size with ambition. A few things that help:

Anchor it in ticket creation. Make the three-function breakdown a required field in your task template. It doesn't have to be formal — even a bullet list in the description works. The act of writing it out surfaces complexity before the sprint starts.

Use it in scope conversations, not just planning. When someone suggests a mid-sprint addition, ask them to define it in function terms. Often, the request either clarifies into something genuinely small, or reveals itself to be a whole separate body of work that needs its own ticket.

Celebrate the split, not the merge. When a team member breaks a large feature into four separate tickets instead of one, that's a win. Treat it like one. The culture shift from "we built a lot" to "we shipped precisely" takes time, but it pays off.

The Bigger Picture

Scope creep is seductive because it feels like thoroughness. It feels like caring about the product. And sometimes, genuinely, it is. But the engineering teams that ship the most consistently aren't the ones who do the most in each cycle — they're the ones who do the right amount in each cycle, and they know exactly what that amount is before they start.

The Three-Function Rule is a small habit with outsized returns. It won't fix a broken planning process or a dysfunctional product org. But if your team has a reasonable foundation and keeps getting stuck in feature sprawl, this is one of the fastest levers you can pull.

One job at a time. Three functions max. Ship it, watch it, and figure out what comes next.