A few weeks ago, I came across a heated LinkedIn debate on estimation in Agile. Some argued that estimation contradicts the Agile Manifesto altogether. The sentiment? Estimating is a waste of time - and possibly harmful.
There’s some truth to this. Estimations often lead to:
Micro-management tendencies
Time-consuming rituals like Planning Poker and long Story Refinement sessions
Inaccurate forecasts
Shifting scopes due to changing priorities make estimations no longer relevant
Padding estimates to avoid risk, rather than encouraging lean delivery
But these critiques mostly apply within the microcosm of the scrum team. And that’s the catch: scrum teams don’t operate in isolation.
Beyond the boundaries of a sprint board lies the rest of the organization - marketing, sales, documentation and training, customer communications, product launches… All these functions rely on the output of scrum teams and need time to prepare. Without at least a rough sense of what’s coming and when, chaos ensues.
That’s why statements like "It’s done when it’s done" don’t scale. While this may align with Agile ideals inside the team, it doesn’t serve the larger business ecosystem, where alignment and coordination are essential. A degree of predictability becomes not just useful, but necessary.
So how do we strike the right balance? How can we uphold Agile values without leaving the rest of the organization flying blind?
The answer lies in pragmatic estimation. Here are some practical strategies to bring structure without bureaucracy:
INVEST in Good Stories: Follow the INVEST principle - stories should be Independent, Negotiable, Valuable, Estimable, Small and Testable. A story requiring more than 5 story points likely needs to be split. Stick to smaller increments (1, 2, 3, or 5) for better control.
Simplify Estimation Where Possible: Not every story needs team-wide discussion. When a story is clear and uncontroversial, the creator or lead developer can assign a story point directly - with care not to overlook hidden complexity. Use team discussions only when there’s real uncertainty.
Timebox Estimation Talks: Don’t spend more than 2–3 minutes per story. If you can’t reach consensus quickly, the story likely needs refining before it’s even ready for estimation.
Use T-Shirt Sizing When Needed: If a story can’t be immediately estimated, assign a rough size - Small, Medium, or Large. You can later virtually map these to story points (e.g. S = 2, M = 5, L = 8) for aggregated planning.
Leverage Volume for Accuracy: Over a large enough set of stories (e.g. quarterly planning), the average story point per ticket becomes quite consistent. You can use this average to estimate remaining work, even when some stories aren’t sized yet.
Reference Stories for Calibration: Anchor your estimations with reference stories - typical examples the team agrees on, like a standard 3-point task - and compare new stories against them.
Build in Realistic Contingency: Always plan for the unexpected. A buffer reduces the need for last-minute firefighting and re-planning across dependent teams. But be careful - too much buffer can kill urgency and trust.
Create Placeholder Stories Early: Even if a story isn’t ready for delivery, log it early with proper metadata, like team, parent epic, target release… Label it clearly as "not ready" to exclude it from delivery and any Agile ceremonies (like estimation), but include it already in aggregated planning views (by probably assigning the average story point size to the story).
Agile isn’t about rejecting planning—it’s about embracing change. But change without structure can be disruptive. By applying estimation in a lightweight, intentional and pragmatic way, you can support not just your team, but the entire organization.
Estimation done right isn’t an anti-pattern - it’s a bridge.
Comments
Post a Comment