Estimation
Perhaps we should rethink and reassess our ritual of story estimation.
Direct from the Scrum creator himself:
Most story estimation is a waste of everybody's time and a recipe for organisational disappointment.
One of the ongoing debates in agile circles is that of story sizing. For years, it has seemed to be a settled topic, but there are always new people entering the field that don't know that it's settled, go out looking for how long something is going to take and find a bunch of information that says you should use story points (or t-shirt sizing, or something similar) to figure out how big something is and get an idea of how long it will take.
So, let's see if we can bring people up to speed. When XP was developed, its creators thought it was important to be able to have an indicative value of the relative complexity of work.
They started with ideal hours, then padded them and then settled on points to abstract away from time, because they found that sizing by hours didn't work very well. Points were never meant to be a predictor of duration.
After a number of years, just about everybody involved in formalising story points realised it didn't work particularly well, for lots of reasons and suggested we move to something else.
Here's Ron Jeffries on how his views of story points have changed:
"I like to say that I may have invented story points and if I did, I’m sorry now."
From Story Points Revisited
For a lot of people, that isn't enough. Knowing that the creators thought it was a mistake isn't enough to enable people to change.
To change, people also need to know what to change to. For that, a detailed breakdown of what to do instead is really valuable. So, here it is:
Why estimating doesn't work:
✔ Parkinson's Law (the idea that work expands to fill the time allotted for its completion. This may mean you take longer than necessary to complete a task or you procrastinate and complete the task right before the due date.)
✔ Optimism
✔ Inherent uncertainty of creative work (This uncertainty stems from the open-ended nature of creative challenges, where there is rarely a single "right" answer or a clear, pre-defined path to a successful outcome. )
✔ Humans are awful at estimating anything bigger than about 2 days of work
What to do instead:
💡 Make stories smaller. No, even smaller. (Hint: See "2 days" above)
💡 Actively seek to understand the uncertainty
💡 Use exploratory stories
💡 Write genuine user stories
💡 Remember that user stories are a placeholder for a conversation
💡 Go talk to the user
💡 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.”
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
What if you need to understand velocity? Simple: count the stories. That's your velocity. Once you make stories really small, their variability decreases and you get through more. The Law of Large Numbers will help eliminate some of the variability you used to see in your work, so counting stories becomes a perfectly reasonable way to measure velocity, if you need to (you probably don't).
- 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.
Sprint "Spillover"
- 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.
Conclusion
Some people will say, "Aha! You said estimating was a waste, but you must estimate in order to figure out if a story is less than 2 days." You're right. But that's the extent of estimation's value. If you understand what's needed well enough, you'll be able to get the story to be smaller than 2 days. If you don't, you won't.
- 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.
Top comments (0)