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.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
The Pitfalls of Agile Burndowns: Stop Being Agile Bandits
Explains why relying on Agile burndown charts leads to over-planning and false progress, and advocates for minimal, adaptive planning and …
The Ghosts of Agile Past: Why Burndown Charts Might Be Holding You Back
Explores why burndown charts can limit Agile teams, highlighting the drawbacks of fixed planning and advocating for adaptability, empirical …
Special Sprints: Agile Banditry or Risk Management?
Explores why special sprints like Sprint Zero or hardening sprints undermine Agile by delaying work, increasing risk, and reducing …
Ditching the Myth of Special Sprints: Embrace True Agile Practices for Usable Products
Explains why relying on special Sprints undermines Agile, and advocates for continuous improvement, accountability, and delivering usable …
Ditching Agile Banditry: Why Story Points and Velocity Metrics Are Undermining Your Team's Success
Explores how relying on story points and velocity can harm Agile teams, advocating for objective metrics like cycle time and throughput to …
Stop treating the end of the Sprint like a finish line
The end of a Sprint is a checkpoint for review and adaptation, not a deadline. Focus on flow, learning, and continuous improvement over …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Kendall Guide - A System of Work for AI Adoption
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Estimating Better in an Overloaded System Is a Poor Man’s Strategy
High work in progress (WIP) causes delays and unpredictability; improving estimates won’t help. Limiting WIP and focusing on flow is key to …
The Definition of Done is a Commitment to Quality
Defines the Definition of Done in Scrum as a clear, shared standard for quality, ensuring increments are releasable, transparent, and …
Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar
Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …
Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Stop confusing acceptance criteria with definition of done, learn the crucial difference to boost quality, speed, and trust in your agile …
How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Unlock a smarter Definition of Done, start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives …
Why Most Transformations Fail Without Honest Conversations
Most transformations fail without open, honest conversations that address real issues, making transparency and tough dialogue essential for …
Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.