Sprint Planning for Fixed-Scope Projects: Our Exact Process

12 sprints. 3 months. EUR 0 over budget. That's how Morta CRM shipped - a full real estate CRM with lead management, property listings, automated workflows, and reporting dashboards. Every sprint delivered working software. The client could have stopped after sprint 4 and still had a usable product.

The industry tells you fixed-scope and agile are incompatible. Agile means flexibility. Fixed scope means rigidity. Pick one. We picked both, and it works because the flexibility lives inside the sprint while the scope stays fixed at the project level.

Key Takeaways > - Fixed scope defines what gets built. Sprints define how and when. These aren't contradictions. > - Every sprint delivers a potentially shippable increment. This means the client gets value early, not just at the end. > - We use a "scope buffer" of 15% built into every project for unknowns, not scope additions.

Why Most Fixed-Scope Projects Fail

Before explaining our process, let's address why fixed-scope has a bad reputation.

Traditional waterfall fixed-scope: Agency writes a 50-page requirements doc. Client signs off. Agency builds for 6 months. Client sees the product for the first time at delivery. It's wrong. Not because the agency screwed up, but because requirements written 6 months ago don't match reality today. Scope was "fixed" but the world moved.

Agency abuse of fixed-scope: Some agencies intentionally underscope to win the deal, then charge for "out of scope" additions. The original quote was EUR 40k. The final bill is EUR 80k. "Fixed scope" becomes a bait-and-switch. This gives the entire model a bad name.

Client abuse of fixed-scope: Some clients treat fixed scope as an unlimited buffet. "The scope says 'user management.' That includes SSO, SCIM provisioning, and role-based access control, right?" No. It includes what was specified in the scope document. Vague requirements become scope disputes.

Our approach eliminates all three failure modes. Here's how.

The Process: Pre-Sprint

Everything starts before the first sprint begins.

Step 1: Scope definition workshop (2-3 days). We sit down (virtually) with the client and define every feature at the user-story level. Not "user management" but "As an admin, I can invite team members via email. As a team member, I can accept the invitation and set my password. As an admin, I can deactivate a team member's access."

Each story gets a complexity estimate: S (1-2 days), M (3-5 days), L (1-2 weeks). Stories larger than L get broken down. If we can't break a story below L, we don't understand it well enough yet.

Step 2: Sprint mapping. Stories get assigned to sprints based on dependencies and priority. Sprint 1 always includes authentication, basic UI shell, and CI/CD setup. Without those, nothing else works.

For Morta CRM, the sprint map looked like:

- Sprint 1-2: Auth, UI shell, database schema, basic CRUD for leads - Sprint 3-4: Property listings, search, filtering - Sprint 5-6: Automated workflows, email notifications - Sprint 7-8: Reporting dashboards, analytics - Sprint 9-10: Admin panel, user management, permissions - Sprint 11-12: Polish, performance optimization, documentation

Each sprint builds on the previous one. The client has a working product after sprint 2. A useful product after sprint 6. A complete product after sprint 12.

Step 3: Scope buffer allocation. We allocate 15% of total project hours as a buffer. On a EUR 60k project (roughly 800 engineering hours), that's 120 hours reserved for unknowns. Not scope additions. Unknowns. The API integration that takes 3 days instead of 1. The edge case in the payment flow that requires extra logic. The database query that needs optimization.

If the buffer isn't used, the project finishes early. If it's fully consumed, the project finishes on time. The buffer has never been insufficient across our projects because we scope conservatively.

The Process: During Sprints

Each sprint follows the same rhythm. No exceptions.

Day 1: Sprint planning (1 hour). We review the stories assigned to this sprint, confirm priority order, and identify any dependencies or blockers. The client attends this call. If they have questions about what we're building, this is where they ask.

Days 1-9: Build. We write code. Daily async standups in Slack. The client sees progress via staging deployments. If we hit a blocker or a story is more complex than estimated, we flag it immediately - not at the end of the sprint.

Day 10: Internal review and QA. We review each other's code, run the test suite, and manually test every story against its acceptance criteria. Bugs found here get fixed in the same sprint.

Day 10 (afternoon): Sprint demo (30 minutes). We show the client what we built. Live. On staging. Not screenshots. Not a slide deck. Working software. The client clicks through the features themselves. They ask questions, flag issues, and confirm acceptance.

Day 10 (after demo): Sprint retrospective (15 minutes). What went well. What didn't. What we'll change next sprint. This is brief because with a 2-person team, most issues are process issues, not people issues.

How We Handle Scope Changes

Here's the contrarian take: scope changes are fine. What's not fine is pretending they won't happen.

Clients discover new requirements during the build. That's normal. A founder watches the sprint 3 demo and realizes the reporting feature needs one more chart type. Or a key integration is more complex than either side anticipated.

Our rules for scope changes:

Rule 1: Changes come from the buffer first. If the new requirement fits within the 15% buffer, we add it. No re-scoping, no price change, no drama. This handles 80% of scope change requests.

Rule 2: Anything beyond the buffer gets formally scoped. If the request is bigger than the remaining buffer, we write it up: what it is, how long it takes, what it costs. The client approves or defers it. No ambiguity.

Rule 3: Adding scope means removing scope (or paying more). If the client wants to add a feature that costs 40 hours and the buffer is used up, something of equivalent size comes out of a future sprint - or the project price increases by the cost of those hours. We present both options and let the client decide.

Rule 4: No scope changes in the current sprint. New requests go into the next sprint's backlog. The current sprint ships what was planned. This protects the sprint cadence and prevents context-switching, which is the biggest productivity killer in software development.

The Morta CRM Example

Morta was our most complex sprint-based project. Full real estate CRM - lead management, property database, automated email workflows, agent performance dashboards, and client portal.

What went right:

- Sprint mapping held up. 10 of 12 sprints delivered exactly what was planned. - The client could demo the product to their agents after sprint 4, getting early feedback that shaped later sprints. - Buffer hours were consumed at a steady rate (about 10 hours per sprint), which told us our estimates were consistently off by about 12%. Good to know for future projects.

What went wrong:

- Sprint 7 (reporting dashboards) was underestimated. The charting library had compatibility issues that cost 20 extra hours. This consumed most of the remaining buffer. - The client requested a feature in sprint 9 (bulk CSV import) that wasn't in the original scope. It was a 30-hour feature. We scoped it as a paid addition (EUR 3,750) and added it to sprint 11-12.

Final accounting:

- Original scope: EUR 60k - Additional feature (CSV import): EUR 3,750 - Total: EUR 63,750 - Delivered: On time, all features working, full documentation

The EUR 3,750 addition was the only scope change that cost money. Everything else fit within the buffer. The client knew about the overage before we built it and approved it in writing. No surprises.

Why This Works Better Than Hourly

Hourly billing with sprints creates perverse incentives. The agency is motivated to fill every sprint to capacity. The client is motivated to cut scope to save money. Every sprint planning becomes a negotiation instead of a collaboration.

With fixed scope:

- We're motivated to ship efficiently. Extra hours don't mean extra revenue. They mean lower margin. So we make smart technical decisions that reduce complexity. - The client is motivated to make decisions fast. Every week of delay doesn't cost them more money, but it delays their launch. The financial incentive to be responsive is built into the model. - Sprint planning is collaborative, not adversarial. We're both trying to ship the best product within the agreed scope. There's nothing to negotiate.

The flip side: if we underestimate, we absorb the loss. This has happened twice in our history. Both times, the underestimation was around 10% of total hours. Painful for margin, but not catastrophic. And both times, we learned something that improved our scoping for the next project.

Our Scoping Accuracy Over Time

We track our estimation accuracy across projects. Here's the data:

- Project 1 (Pushary): 8% overestimate. We finished early and used the extra time to add polish. - Project 2 (Morta CRM): 3% underestimate (before the paid addition). Absorbed within buffer. - Project 3 (Shamaze): 5% overestimate. Delivered 4 days early. - Project 4 (Equipment Rentalz): 7% underestimate. Buffer fully consumed. Delivered on time.

Average estimation accuracy: within 6% of actual hours. That's tight enough for fixed-scope to work reliably. The key is experience - we've now shipped enough similar projects that our estimates are based on historical data, not guesswork.

Frequently Asked Questions

What happens if a sprint falls behind schedule?

We've never had a sprint fail completely, but we've had sprints where one story didn't get finished. When that happens, the incomplete story moves to the next sprint as highest priority. We identify why the estimate was wrong (usually an unforeseen technical dependency) and adjust future estimates. The project end date doesn't move because our buffer accounts for exactly this scenario.

How do you handle client delays (slow feedback, missing assets)?

The contract includes a "client responsibility" clause with response time SLAs. Sprint demos require feedback within 2 business days. Asset delivery has deadlines tied to specific sprints. If the client is late, the sprint starts without their input and we make the best decision based on what we know. If the delay is significant (more than 1 week), the project timeline shifts by the same amount. We don't absorb client-caused delays.

Can this process work for smaller projects like marketing sites?

For a EUR 5k marketing site, full sprint planning is overkill. We use a compressed version: scope in 2 hours, build in 48 hours, one review round. Sprint-based planning shines on projects with 4+ weeks of development time where priorities might shift and incremental delivery creates value.

How do you decide what goes in sprint 1 vs later sprints?

Sprint 1 always contains the minimum infrastructure for everything else: authentication, deployment pipeline, database schema, and one core feature. After that, we prioritize by user-facing value. Features that let the client demo the product to real users go early. Admin features and polish go late. The client always has input on priority, but we advise on technical dependencies.

*Want to see our sprint planning in action? Book a 30-minute call and we'll walk you through how we'd plan your project. Or explore our services to find the right engagement model for your build.*