Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
Estimation
Perhaps we should rethink and reassess our ritual of story estimation.
Direct from the Scrum creator himself:
The Fallacy of Estimates
Perhaps we should rethink and reassess our ritual of story estimation.
Direct from the Scrum creator himself:
The Fallacy of Estimates
- 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.