How many story points should your team be delivering? That’s the sort of questions I heard more than enough when helping new teams. I see metrics deriving from it and big discussions about the most precise or more effective method for estimation.
The funny thing is that the word estimation and precision are at odds. In its etymology, estimates are a guess, a judgment, an evaluation of the size, cost or weight of something. If you look at a wall and guess its height this is estimation. If you take out your measuring tape… your are measuring. One is a guess. The second, a validation.
It is very important that the Agile leader, that’s right you, Scrum Master, Agile Manager, Agile Coach, etc., that you set the expectations right on this topic. Estimates do not get better with time, as in “becoming a better guesser”. Also, different teams do not become better at estimating equally. Being different teams they will always have a different rhythm and viewpoint. Thinking otherwise is more a tradition from the waterfall times, in which time, scope and budget were all fixed and work just needed to fit the space allotted. That is not how Agile works, because Agile is about understanding the emergence of conditions and even emergence of work. And making the trade-offs that are necessary based on the conditions and of change.
Now, despite that, estimating can actually be very useful. No, this post is not some mind-bending approach on estimate-but-not-estimate. Let me describe some of the reasons I feel the act of estimating, for a team, just like planning, is still useful.
Why estimate?
My most important argument on why we should estimate has to do with understanding the work. If I think something takes me two days and you think it takes two hours we’re clearly not talking about the same scope or we sit on dramatically different skill level. So we need to share our views and get into an agreement. Estimating unveils hidden assumptions, sharpens acceptance criteria. The whole team must be in agreement of what the work represents. That’s why many teams adopt the practice of poker planning. Not only is it fun, it is elucidative, because our first ideas are the most unbiased and there is where we will find the important disagreement that opens up the discussion of scope. It is healthy.
Estimates are not commitment
If estimating is a practice to understand work, it is still a guess. We limit some scope creep, but the fact we say something is small or that it takes 3 ideal days does not make it true. It is ballpark. We are not committing to a number of hours or to a very specific date. Again, this obsession with being able to know exactly when to deliver is a tradition from waterfall, which by the way, never really worked. How many projects have you seen late? Probably more than you can remember. And that is normal, especially in a market where the solutions and products are getting more and more complex.
Agile estimation calls for 3 things:
- Estimate as a team: in a collaborative environment, where we commit as a team, it only makes sense that we estimate as a team as well. Everybody has a say, no matter if they are junior or senior, if they are testers or developers.
- Use relative estimation: it is more useful to look at upcoming work comparing it to work already done. Is it harder or easier than that security API that we deployed last week? Is it more complex than the reconciliation report? Relative estimation helps you to land on degrees of difficulties, such as Fibonacci sequence, T-shirt size or banana, apple and watermelon. To know more about these 3 techniques, read the end of this article.
- Discuss the results: nothing is done until the conversation happens. If everybody gave their opinion using relative estimation, we’re still not doing Agile estimation if we do not allow the space for actually understanding and framing scope, as mentioned before. we’re less interested in the number and more interested on what do we do from here.
What makes it #noestimates? Basically stopping after the discussion of the results. Throwing the estimate out and either committing or not for the that particular piece of work for next iteration. And that is the main difference. Getting rid of this velocity & other vanity metrics that show precise numbers about imprecise things.
“When will it be done?” That’s forecasting.
We work in the realm of VUCA (Volatility, Uncertainty, Complexity and Ambiguity). Certain things are just in general more complex and you can only simplify so much. You cannot eliminate all of the unknown things, no matter how much scope you cut. You cannot guarantee that team members will not call in sick. You cannot even guarantee you have the same level of work performance today versus tomorrow. The obsession of the precise estimate (again, the oxymoron) denies natural elements such as the complexity of life events or our own human nature.
And on the same vein, in most companies where I see this obsession in place there is a combined ignorance of forecast practices. Attempting to predict when something will be finished is called forecast, not estimation. Forecasting is just like attempting to prevent stock market positions or tomorrow’s weather. The farther from a specific date you are, the more the chances that the prediction is wrong. And what is required is tools able to do massive calculations based on mathematical models and in historical data.
And there is more: in order to operate on forecasting, managers and stakeholders need to start getting familiar and comfortable with the notion of probability: answers of when things will probably get done with a 50% or a 75% chance of certainty. If that is something you are interested in knowing more about, Troy Magennis has a thing or two to say about this.
As we approach the end of this post, I’d love for you to leave with the following thoughts:
- Estimating is useful for teams to get agreement on the scope of work.
- Estimates are not commitment or promises on dates.
- Estimation does NOT drive throughput (amount of work completed). Forecasting is what you want for that.
- If you estimate wrong, throughput is still your reality.
If you are in need to better understand estimation x forecast, read more in this blog post.
Are you ready to do #noestimates with your team?
Quick Bonus: Three ways to do relative estimation
Story points
Story points are widely known in Agile. Through it you give your user stories (or any piece of work, really) a number based on the Fibonacci sequence. Fibonacci goes like this: 1, 2, 3, 5, 8, 13, 21… As you can see, each number is equal the sum of the previous two. What is great about this sequence is how the numbers start compounding heavily. Between 2 and 5 you might have only 1 number, but in fact the numeric difference is more than double. As a common practice, between numbers 8 and 21 teams tend to use those numbers to say “this is too big, we need to break it down more”.
So, in a normal porker planning session, team members show numbers 5, 3, and what else, and discuss to see where the divergence is. Usually big gaps, such as a 3 and an 8 are great indications that there is too much room for scope creep, for dependencies or a lot of unknowns and the acceptance criteria for the work needs to be defined favoring the smallest useful piece of work. Go further in your understanding of this practice in another blog post here.
* Fibonacci unlocks other cool stuff such as the golden ration and funky fractal calculations. It actually starts as 0, 1, 1 and continues infinitely. If you are the geeky type, check out its Wikipedia.
T-Shirt size
You can still do poker planning using something other than Fibonacci. As the name implies, T-shirts and articles of clothing have a general accepted range from Small to Large, with the now interesting XXSmall and XXLarge. Teams who adopt this gauge have a range that goes from 3 sizes (S-M-L) to as many as they want (some teams have XXXS and even in-between such as SM and ML).
All the elements of Agile estimation are present. The whole team takes part, individually giving a size from the range they use. Then, they discuss it as a team and decide what to do with the piece of work: break down some more, commit to it or ask for more information.
Banana, Apple, Melon
The last piece is a staple of relative size estimation. Have fun developing your own gauge and even taking inspiration from culinary arts. The whole idea from this method is to use images that the whole team agrees and put them in a range.
Suppose your range of work is how to peel a fruit. A banana represents your easiest as you can do that anywhere, anytime, with your hands. An apple is the next in the range, requiring a tool to be peeled off. The next on the scale is the melon, which no matter the tool is still rather awkward to peel off. So when the team says a work piece is like a banana, they are in agreement on how easy it is to basically just execute on the work. But when they say melon, you know it means hard work ahead. In this case, just like for the other estimation types, when you reach a big, confusing, hard piece of work, might as well defer the commitment or break work down into smaller pieces.
