Environment: preview · Version: v0.2.0-preview.10

Videos

Rethinking Sprint Planning: Why Burndown Charts Are Agile Banditry and What to Do Instead

A common practice I observe among agile teams is the reliance on burndown charts to gauge progress throughout a Sprint. However, I must confess, I view burndowns as a form of agile banditry. The premise of a burndown chart is that for it to move smoothly from the top left to the bottom right, you must have meticulously planned the entire Sprint upfront. But let’s be honest, when we’re developing products that don’t yet exist, this approach is fundamentally flawed.

The Reality of Product Development

In the world of product development, especially when venturing into uncharted territory, we face a plethora of unknowns. According to the Standish Group’s Chaos Report, a staggering 65% of what we build changes over the product’s lifecycle. Even more concerning is that only 30% of the features we develop are actually utilised by our customers. This data underscores a critical truth: we often know less than half of what we need to figure out as we progress.

Given this level of uncertainty, attempting to plan even the next 10-day Sprint is akin to spinning a fictional tale. Instead, I advocate for a more pragmatic approach.

Sprint Planning: Less is More

When you walk out of Sprint planning, your plan should be minimal yet sufficient to get started. Ideally, you should leave with just enough to kick off the Sprint, perhaps a mere 24 hours’ worth of work. This allows for flexibility and adaptability, enabling you to reassess and plan again every day.

  • Key Takeaways for Sprint Planning:
    • Start Small: Focus on what you need to begin, not on an exhaustive list of tasks.
    • Daily Reassessment: Plan for the next 24 hours and adjust as necessary.
    • Minimise Overhead: The less you have to manage, the more streamlined your process will be.

The Burndown Banditry

The issue with burndowns lies in their tendency to encourage excessive upfront planning. Imagine you have five developers and five stories, each with ten tasks. You end up with a mountain of tasks to manage. What happens on day two when you discover that half of your plan needs to change? You’re left scrambling to update a backlog that’s already out of date, diverting focus from delivering value.

Instead of getting bogged down in a sea of tasks, I recommend adopting a just-in-time, just-enough planning approach. This means having a clear, concise plan for your Sprint or product that allows for immediate action without the clutter of unnecessary tasks.

Embrace Continuous Flow

Let’s shift our focus from being agile bandits to fostering a continuous flow of value through our systems. If you find yourself ambushed by agile banditry in your organisation, my team at Naked Agility is here to help. We can assist you in navigating these challenges or connect you with a consultant who can provide the expertise you need.

If you found this discussion valuable, don’t forget to like and subscribe for more insights. Together, we can break free from the constraints of outdated practices and embrace a more effective, agile mindset.

Debug: Kind=page | Type=videos | Layout= | Section=videos
Bundle files (7):
Page template:site\layouts\single.html