A field guide to scoping a two week app sprint

Almost every project that comes to us starts the same way: we need an app for tracking X. By the end of a twenty minute call, X has usually split into three or four different things wearing one name.

The tell that a scope is too big

If a workflow needs more than one type of user with meaningfully different permissions, more than one approval stage, and more than one system it has to talk to, it is not one sprint. It is two, and trying to force it into one is how a two week estimate becomes an eight week apology.

What we actually ask on the call

• Who logs the first entry, and what do they see on day one?
• Who approves it, and what happens if they reject it?
• Where does the data need to end up: a dashboard, an export, or another system entirely?
• What is the one thing that, if it did not work on day one, would make this a failure?

That last question does more work than the other three combined. It forces a client to name the actual point of the app, instead of the wish list around it.

What gets cut, and why that is good news

Almost every scoping call ends with something removed, not added: the export nobody actually opens monthly, the second approval tier that exists on paper but never triggers in practice, the dashboard view that was requested before anyone had data to put in it. Cutting these is not a downgrade. It is the difference between a tool your team opens every day and a feature nobody remembers to use.

A sprint that ships in two weeks is not a smaller version of what you asked for. It is the sharpest version of what you actually need, with everything that was not load bearing removed before the first line of code.