Beyond the Basics: Iterative Planning

Everyone says they do iterative planning. Most teams don’t, not really. They plan in iterations. Two-week sprints, quarterly roadmaps. But the planning itself isn’t iterative. It’s a waterfall planning sliced into shorter cycles.

Real iterative planning means your plan evolves based on what you learn. You don’t just ship in iterations; you use each iteration to validate assumptions, gather evidence, and adjust direction. The plan you start with is deliberately incomplete because you know you’ll learn things that change it.

I learned this distinction painfully where we “planned iteratively” using two-week sprints. Except we’d planned the entire quarter upfront — just broken into sprints. When we discovered in week three that our core assumption was wrong, we kept building anyway because “it was on the roadmap.” That’s not iterative planning; that’s iterative execution of a fixed plan.

Contrast that with another team, where we deliberately left 40% of the roadmap unplanned, knowing we’d learn things that changed priorities. Each sprint, we’d review what we learned, what changed, and what to do next. Uncomfortable at first, but it meant we were always building the right thing based on current knowledge, not stale assumptions from three months ago.

Scaling What Works

Growth considerations

Early on, iterative planning is easy. Five people in a room can pivot quickly when plans need to change. At 50 people with dependencies between teams, dependencies on external systems, and commitments to customers, pivoting is expensive.

The challenge: maintaining iteration speed whilst scaling coordination.

We tried to maintain complete planning flexibility as we grew. Result? Chaos. Teams couldn’t coordinate, dependencies broke constantly, and nobody could commit to timelines because “we’re iterating.” Customers got frustrated by unpredictable delivery, sales couldn’t sell confidently, and engineering was constantly switching context. The definition of hell.

The fix isn’t abandoning iterative planning, but creating structure that enabled iteration within constraints.

Solution? Planning horizons: Firm commitments for 4-6 weeks (things in flight, dependencies locked), flexible plans for 6-12 weeks (directionally right but details might change), and options beyond that (things we might do based on learning).

This give teams enough certainty to coordinate whilst maintaining flexibility to iterate. Sales can commit to features in the 4-6 week window (ok, this part is not really ideal, because most request are in the “I don’t know bucket”). Engineering can (better) plan capacity. But what is preserved is the ability to change direction based on learning beyond that window - and this is key.

The key insight: Iterative planning at scale needs clear boundaries between what’s locked (for coordination) and what’s flexible (for learning). Without that distinction, you get either chaos or false iteration.

Maintaining quality

Iterative planning has a dark side: teams use “we’re iterating” to justify shipping rubbish and fixing it later. That’s not iteration; that’s lack of standards dressed up in agile language.

“Ship and iterate” can easily become an excuse for shipping half-baked features. Customer complaints will come in, you’d say “we’ll iterate on that,” and move on to the next thing. The backlog of “iteration work” grews into hundreds of items that are never fixed. You’d iterated yourselves into a mess.

The fix: distinguish between learning iterations (deliberately shipping incomplete to validate assumptions) and quality iterations (shipping properly, then enhancing).

Learning iterations are fine when you’re testing whether something works at all. Build the simplest version, see if it solves the problem, then decide whether to invest more.

But once you’ve validated the need, quality matters. When you know people will use something, ship it properly. Don’t use “iteration” as cover for cutting corners.

At one company, we implemented a simple rule: learning iterations have explicit hypotheses. If you’re shipping something incomplete, you must state what you’re trying to learn. If you can’t articulate the learning goal, you’re not iterating, you’re shipping incomplete work and hoping nobody notices.

This forced clarity. Sometimes teams realised they weren’t actually testing anything; they were just under-delivering. Sometimes they articulated clear hypotheses, gathered evidence, and made informed decisions about next steps. The difference became obvious.

Implementation Approach

Best practices

Start with the outcome, not the plan. Traditional planning starts with “what should we build?” Iterative planning starts with “what outcome are we trying to achieve, and what’s the smallest thing we can ship to make progress?”

At one company, we wanted to “improve onboarding.” Traditional approach: spend six weeks building comprehensive onboarding flow with videos, tooltips, progress tracking, and email sequences. Iterative approach: identify the specific drop-off point causing most harm, ship the simplest fix for that one point, measure impact, then decide what’s next.

We found that most of drop-off happened at account creation because users didn’t understand the value proposition. The “smallest thing” was rewriting three sentences on the signup page. Took two days. Improved conversion. That learning shaped what we did next, which wasn’t the comprehensive onboarding flow we’d planned.

Time-box discovery work. Iterative planning can become “endless research and never shipping.” Set hard time limits for validation work.

Our rule: two weeks maximum to validate an assumption before deciding. If you can’t get meaningful signal in two weeks, you’re asking the wrong question or over-engineering the test.

At one company, our team spent six weeks “validating” whether customers wanted a feature. We built prototypes, ran interviews, analysed data. After six weeks, we still weren’t sure. The issue? We were trying to get certainty when we should’ve been gathering conviction. We pivoted: ship the simplest version in two weeks, see if anyone uses it. Usage data was clearer than six weeks of research.

Bake in reflection rituals. Iteration requires learning from each cycle. If you don’t systematically reflect on what you learned, you’re not iterating, you’re just doing things in short cycles.

Every sprint, we’d spend 30 minutes on three questions:

What did we learn this sprint that changed our thinking?
What should we do differently next sprint based on that?
What do we need to learn next?

This forced us to extract learning and apply it. Without this, teams would ship, ship, ship without ever asking whether we were building the right thing.

Tooling and process

Keep tooling deliberately simple for iterative planning. Complex tools create planning debt, the cost of maintaining and updating elaborate plans, that kills iteration speed.

At one company, we used Jira with detailed epics, stories, acceptance criteria, and estimates for everything. Planning a quarter took three weeks. When priorities changed (which they did often), updating all that detail took days. The tool prevented iteration.

We simplified radically: one backlog, three priority buckets (doing now, doing next, might do), rough sizing (small/medium/large), and minimal documentation. Planning a sprint took 45 minutes. Changing direction took 30 minutes. The simplicity enabled iteration. It’s not about having speed-plannings. You can spend more time working on wireframes, diagrams to better plan out and understand where the juice could be.

The tools that work for iterative planning:

Living roadmap documents (Google Doc or Notion, not elaborate roadmap tools). Written in plain language, updated weekly/bi-weekly, focused on outcomes and assumptions rather than features and timelines. Takes 10 minutes to update, always reflects current thinking.

Simple kanban boards (Linear, or similar). Visualise what’s in progress, what’s next, what’s blocked. No elaborate workflows or statuses. If you can’t explain your board in 30 seconds, it’s too complex.

Lightweight decision logs. Record important decisions, the reasoning, and what you hoped to learn. When you iterate, you can see whether your assumptions held up. We used a simple Notion database: date, decision, reasoning, expected outcome, actual outcome. Reviewed quarterly to improve making decisions.

The pattern: favour simple, fast tools over comprehensive, slow ones. Iteration speed matters more than planning precision.

The Development Context

Technical considerations

Iterative planning only works if your technical architecture supports iteration. If every change requires weeks of engineering work, you can’t iterate, you’re stuck with whatever you built first.

At one company, the architecture was so coupled that “iterating” on a feature meant rewriting major systems. Result? We’d ship something, learn it was wrong, and couldn’t afford to fix it because the technical cost was too high. We’d painted ourselves into corners.

The technical enabler: modular architecture that lets you swap components without rewriting everything. When onboarding wasn’t working, we could replace the signup flow without touching the rest of the system. When a feature wasn’t used, we could remove it without breaking dependencies.

This isn’t about microservices or specific architecture patterns. It’s about designing systems that expect change. Loose coupling, clear interfaces, feature flags, and separation of concerns. These patterns make iteration cheap instead of expensive.

Feature flags were particularly valuable. We could ship features to 10% of users, learn whether they worked, then roll out or roll back cheaply. This enabled true iteration. Test, learn, adjust, without the cost and risk of full releases.

Team dynamics

Iterative planning requires different team behaviours than traditional planning. You need comfort with uncertainty, willingness to change direction, and tolerance for work being “thrown away.”

At one company, engineers were frustrated by iterative planning. They’d build something, we’d learn it wasn’t quite right, and we’d change direction. They felt like their work was being wasted.

The mindset shift: we’re not building features; we’re learning what to build. Early iterations that get thrown away aren’t waste, they’re the cost of discovery. Better to spend two weeks learning you’re on the wrong path than six months building the wrong thing.

We started framing work differently. Instead of “build this feature,” we’d say “test whether this approach solves the problem.” Engineers understood they were running experiments, not shipping final products. That framing made iteration feel less wasteful.

The cultural shift needed: From “predictability and hitting commitments” to “learning and adapting quickly.” Both matter, but iterative planning prioritises learning over predictability in early phases.

We introduced two tracks: discovery track (fast iteration, cheap learning, expect things to change) and delivery track (validated direction, ship properly, commit to timelines). Making the distinction explicit helped teams know which mode they were in and what success looked like for each.

Key Takeaways

Iterative planning means the plan evolves: You don’t just ship in iterations, you use each iteration to validate assumptions and adjust direction. The plan you start with should be deliberately incomplete.
Define planning horizons: Firm commitments for 4-6 weeks, flexible plans for 6-12 weeks, options beyond that. This balances coordination needs with iteration speed.
Learning iterations need explicit hypotheses: If you’re shipping something incomplete, state what you’re testing. If you can’t articulate the learning goal, you’re not iterating, you’re under-delivering.
Start with outcomes, not plans: Ask “what outcome are we trying to achieve and what’s the smallest thing we can ship to make progress?” Don’t start with “what should we build?”
Time-box discovery: Two weeks max to validate an assumption. If you can’t get meaningful signal in two weeks, you’re asking the wrong question.
Build reflection rituals: Every sprint, ask: What did we learn? What should we do differently? What do we need to learn next? Without reflection, you’re doing short cycles, not iteration.

Final Thoughts

Most teams think they do iterative planning because they use sprints. But sprints without learning are just waterfall planning in short cycles.

Real iterative planning means accepting uncertainty, building to learn, and changing direction based on evidence. It’s uncomfortable because you can’t predict exactly what you’ll build three months from now. But it’s the only way to ensure you’re always building the right thing based on current knowledge, not stale assumptions.

The teams that excel at iterative planning aren’t the ones with the most sophisticated processes. They’re the ones comfortable saying “we thought we were building X, but we learned Y, so now we’re building Z instead.” That flexibility, changing direction based on learning, is the whole point.

This week, look at your current plan. How much of it is based on assumptions you haven’t validated? What’s the smallest thing you could ship to test those assumptions? Don’t wait for the perfect plan. Ship something small, learn from it, and let that learning shape what’s next.

That’s iterative planning. Not perfect plans executed in short cycles, but imperfect plans that improve as you learn.

Have questions or thoughts? Get in touch - I’d love to hear from you!