Mastering the Shape Up Betting Table for High-Signal Engineering Planning

Running A Better Table

Steve McDougall defines the betting table as the high-stakes meeting where senior leadership and engineering commit to six-week cycles. This operational framework acts as a structural defense against the organizational pressure that typically collapses agile sprints into endless backlog grooming.

Why This Matters

The technical reality of software development often clashes with ideal models when stakeholders inject ‘pseudo-urgent’ requests that lack proper shaping. By enforcing a binary decision-making process at the betting table, teams resist the cost of distributed debt and avoid the ‘estimate with extra steps’ trap, ensuring that only fully-vetted pitches consume engineering capacity.

Key Insights

• Written pitches are a mandatory prerequisite for the betting table; verbal or half-formed proposals are rejected to ensure work is thought through (McDougall, 2026).
• Decision-making authority must be restricted to senior leadership and engineering leads to avoid the quality-diluting effects of consensus-based planning.
• The ‘No-Carry-Over’ rule forces an explicit abandonment of unselected pitches, preventing the infinite growth of low-value backlogs.
• The ‘Circuit Breaker’ mechanism terminates projects that exceed their six-week appetite, maintaining the integrity of the time-box constraint.
• The two-week cooldown period is a non-negotiable requirement for addressing technical debt and shaping future work, rather than a buffer for overruns.

Practical Applications

• Use case: Leadership reviews shaped pitches during the cooldown to commit the next cycle’s focus. Pitfall: Including too many people leads to diluted decisions and poor-quality bets.
• Use case: Implementing the circuit breaker to stop a project that hasn’t finished in six weeks. Pitfall: Allowing automatic extensions turns fixed appetites into aspirational estimates.
• Use case: Protecting engineering capacity for technical debt during the cooldown. Pitfall: Filling the cooldown with support tasks or catch-up work from the previous cycle.

References:

• https://dev.to/juststevemcd/running-a-better-table-4175