Rethinking Estimation In Agile Development

Estimation

Perhaps we should rethink and reassess our ritual of story estimation.

Direct from the Scrum creator himself:

Estimates are inherently based on guesswork.
Estimation leads to dysfunction and false commitments.
It's not that things are late 80% of the time; it's that we don't know how to do estimates 80% of the time, so our estimates are always wrong.
Making decisions based on erroneous estimations leads to significant process breakdown.
Story points have no meaning, any more than time-based estimates would have.

Velocity is a ratio that compares the hypothetical time needed to complete a project without interruptions to the actual time it takes in practice.
Essentially, it's a decimal figure ranging from 0 to 1, similar to a percentage.
Our wrong estimates are tied into this.
We wrongly attribute decreased velocity to team inefficiency rather than acknowledging systemic barriers (e.g., bureaucratic processes and unnecessary tasks).
Velocity is another destructive force, often misinterpreted as a measure of efficiency or productivity.

In Agile methodology, there's no concept of Sprint "spillover."
Agile embraces change, even during coding, allowing for feedback-driven adjustments.
Insisting on estimation often means misunderstanding Agile, resorting to what is termed as "fake Scrum."
True Agile doesn't require committing to a fixed set of stories within a Sprint; instead, it focuses on committing to overall goals, emphasizing adaptability over rigid planning, similar to traditional waterfall approaches.

Combines the flexibility and continuous workflow of Kanban with the structure and predictability of Scrum.
Get the best characteristics of each and preserve them.
Utilizes short iterations of 1-2 weeks while embracing continuous releases.
Incorporates sprint planning and review while allowing flexibility and no commitment.
No notion of story points or “points per sprint.”

It's time to move away from the culture of estimates and focus on delivering valuable software.
If we are obsessed with estimates, let's employ a difficulty scale that is difficult to translate into time.
- For example, categorize tickets as trivial, easy, normal, hard, don't know, etc.
- This could provide valuable information for prioritization.
Adopt Scrumban and get the best of both worlds.