The Betting Table

You can't plan 12 months ahead when the tools you're building with didn't exist 6 months ago.

That's the problem with traditional Agile in 2026. Sprint planning assumes a predictable future, two-week sprints roll into quarterly roadmaps that feed annual plans. But when Claude Code can rebuild an entire website in a weekend and your competitive landscape shifts every model release, that planning horizon becomes a liability.

Here's what we're running with our clients instead.

Run 6-week cycles where you make one focused bet instead of maintaining a backlog. Define your appetite (time + people), shape the solution to fit, and don't interrupt mid-cycle. Ship, learn, bet again.

Traditional Agile was designed for a world where software development had predictable velocity. You could estimate story points, calculate team capacity, and forecast delivery with reasonable accuracy because the underlying technology changed slowly.

AI doesn't work that way.

Three months ago, a feature might've required custom model training and weeks of engineering effort. Today, it's a 200-line Claude prompt. Last quarter's technical impossibility is this quarter's afternoon project. Your carefully groomed backlog becomes obsolete before you finish the sprint.

Here is how it plays out. A team plans a quarterly roadmap in December, and by February half the features are either unnecessary (Claude can do it better) or dramatically simpler to build than estimated. The other half need complete rethinking because new capabilities opened better approaches.

The roadmap wasn't wrong when they made it, the world just moved faster than quarterly planning allows.

Instead of maintaining a backlog and committing to quarterly deliverables, you run 6-week cycles with three key differences.

1. You make bets, not commitments:

At the start of each cycle, you decide what single bet is worth making for the next six weeks, not a list of features, not a prioritized backlog, just one focused investment.

The question isn't "what can we fit in?" It's "what's the right bet to make right now?"

This forces real prioritization. You can't hedge, can't do three medium things. You pick the one thing that matters most for the next six weeks, given what you know today.

2. You define appetite, not scope:

Traditional Agile estimates effort, then commits to scope. Betting table thinking flips this.

You decide how much you're willing to invest in an idea (your appetite), then shape the solution to fit that constraint. If your appetite is three weeks with two people, the solution needs to deliver meaningful value within that box. If it doesn't fit, either the appetite was wrong or you need a different approach.

In practice a team might say: "Our appetite is three weeks with three people on this idea. We're going to do a three-week version of it, not spend three weeks trying to fit a six-week idea into a three-week timeline."

That distinction matters. You're not cramming scope into time. You're shaping the solution to match your investment appetite.

3. You don't interrupt cycles:

Once a cycle starts, it runs for six weeks. No new requests, no scope changes, no "quick wins" that derail focus.

If something urgent emerges, it waits. Urgency is almost always a planning failure, not a real emergency, and even real emergencies are better handled by finishing the current cycle fast than by context-switching.

The discipline of not interrupting creates space for actual depth of work. You're not constantly re-planning; you're executing.

We rebuilt the StealthX website last month, complete redesign, new features, migration from WordPress to React, tested and deployed.

Time invested: Two weekends.

That's not a humble brag. It's an example of radically different execution velocity when you have the right tools and no process overhead. Claude Code handled most of the implementation while I shaped what needed to exist and why. The tool handled how.

Could we have estimated that in story points? Assigned it to a sprint? Sure. But the planning would've taken longer than the work.

Here's what that looks like on a smaller question. Say a team needs to validate whether their data architecture can support an AI-powered analytics feature. Traditional approach: spec it out, estimate it, put it in the backlog, wait for capacity.

Betting table approach: "Our appetite is one week. Let's build a proof of concept that answers the core technical question. If it works, we'll know the architecture holds. If it doesn't, we'll know what needs to change."

Run the experiment. If it works, make the next bet with confidence. If it doesn't, you learn in days what a backlog would have taken a quarter to tell you.

The speed isn't the point. The learning velocity is the point.

Look, the betting table isn't right for every team. It works best when:

You're building in a rapidly changing technical landscape:

If your tools and competitive environment are stable, traditional planning works fine. If they're changing monthly, you need a methodology that embraces uncertainty instead of fighting it.

You have senior execution capacity:

This approach requires people who can shape problems, make decisions, and execute with minimal process. If your team needs detailed specifications and constant oversight, stick with Agile.

You're optimizing for learning speed, not predictability:

Stakeholders who need detailed roadmaps and delivery dates six months out won't like this approach. Stakeholders who want to move fast and learn what works will love it.

You can afford to make bets:

Some contexts require guaranteed delivery, regulatory compliance, contractual obligations, critical infrastructure. Those aren't bets; they're commitments. Use a methodology designed for guaranteed delivery.

But if you're building product in a competitive market, you're already making bets whether you admit it or not. This approach just makes them explicit.

Teams using this approach ship meaningful updates every six weeks instead of every quarter. They're making technical decisions based on what's possible today, not what was possible when they planned three months ago.

Here's what actually happens when teams make this shift, they stop maintaining backlogs that become technical debt. Every six weeks they reassess: What's the right bet now? Not what did we commit to in December, but what makes sense given everything we've learned?

Teams that make this shift stop spending weeks planning the quarter and spend a couple of hours shaping the next bet. They ship more and plan less.

That's the trade. Less predictability for more velocity. Less comfort for more relevance.

For teams building AI-forward products in 2026, that's not a trade, it's a requirement.

If you want to try this approach, here's the minimum viable version:

1. Pick one thing for the next six weeks:

Not your top three priorities. One bet, the thing that matters most right now.

2. Define your appetite:

How much time and people are you willing to invest? That's your constraint. Shape the solution to fit it.

3. Commit to not interrupting:

For six weeks, nothing else gets added. Finish the bet, learn what you can, then reassess.

4. Review and bet again:

At the end of six weeks, share what you learned. Then make the next bet based on what you know now.

That's it. No burndown charts, no velocity tracking, no story points. Just focused bets and fast learning.

The Shape Up book covers this methodology in depth and it's freely available online. We've found it pairs exceptionally well with AI-forward development because it embraces the reality that you can't predict what's possible six months from now.

You can only bet on what makes sense today, ship it, learn from it, and bet again.

Here's the real shift, the betting table isn't about cycle length. It's about accepting that speed and certainty are inversely related when you're building in environments that change faster than you can plan for them.

Traditional Agile tries to create predictability through process, estimation, velocity tracking, commitment to scope. It works when the underlying system is stable.

AI development isn't stable. The capabilities available to you today weren't available last quarter. The capabilities available next quarter don't exist yet. Trying to plan for that with Agile is like using a paper map when the roads are being rebuilt while you drive.

You need a methodology designed for change, not despite it.

That's what the betting table gives you. Not perfect predictions, not guaranteed delivery dates, just the ability to make smart bets, learn fast, and adapt before your competition does.

For teams building AI-forward products, that's the only sustainable advantage.

Want to talk about how this approach might work for your team? We run workshops on AI-forward product development and can help you make that first bet with confidence.