SAFe Mix-in’s: #NoEstimates
The idea behind #noestimates is that one of the biggest problems that many folks in the agile community face is the estimation process. Estimation takes an inordinate amount of time, it’s often terribly inaccurate and it doesn’t buy us a whole lot in terms of additional value at the end of the day. So why not get rid of estimates entirely?
Overview
I want to admit that #noestimates is one of the more radical ideas in the agile community. This isn’t for everyone. But if you’re feeling brave, and maybe a little inquisitive, I’ve summarized some references from some folks who have been central to the #noestimates movement below:
The NoEstimates Movement– Ron Jeffries
Doing Scrum Without Estimates– Neil Killick
Can We Code Without Estimates– Woody Zuill
Story Points Considered Harmful or Why?– Vasco Duarte
#noestimates really boils down to focusing on small chunks of work and using throughput or other methods as a replacement for story points and associated agile estimation practices. There are a lot of good reasons for us to be suspicious of some of the commonly accepted agile estimation techniques.
The Problem with Estimates
Now there are people who say that estimates are necessary in order to do business. That you must have some idea of the size of what you are going to accomplish by a given time. I don’t think anyone would deny that some forecast of future delivery is needed (although less relevant the shorter the timeframe gets). However, that also doesn’t necessarily mean that we should be investing huge amounts of energy to provide that information. In fact, we should be doing the lightest weight thing that we can manage in order to get reasonable feedback for planning. And in many cases, it’s much more important to talk about the work and how we are going to manage that work rather than obsessing on sizing the work. My experience has been that often times sizing the work has come to overwhelm us, even in the agile community. Perhaps especially in the agile community.
Initially, things like story points were introduced as experiments to see if we could find a better way to have a good conversation about estimation. That seemed to be an improvement over task hours and the typical tools used by project managers back in the day. Now as it has played out over time, that strategy hasn’t really played out well for us. In fact, if I never have to tell another person what a story point is again, it will be too soon. Story points have been used and abused to such a great degree that it’s really hard to see their value anymore.
Now what do you do without some form of estimation? Troy Magennis has made the point that how you do estimation depends on what your constraints are. There are usually a couple of constraints that we can consider in estimation: size and delay. If the work you are sizing is dependent on another piece of work, and there is a delay in that dependency, then your estimate of work size can be rendered meaningless. In fact, it is often the case that the delays can be longer that the duration of the work itself. When you are in a situation like that, it no longer matters what the size of the work is. The most important consideration in that case is the duration of the delay instead. So traditional size-oriented estimation falls apart in this scenario. So, there are some serious flaws with current estimation techniques.
With that in mind, perhaps we need to consider that putting a lot of energy into sizing the work is a waste of time. In fact, if you take a look at the work that is commonly done prior to PI planning in SAFe, especially for large value streams, you’ll find that it is very likely to be heavily oriented toward this kind of exhaustive and very wasteful style of estimation. You’ll start at the beginning of the quarter by estimating your initiatives (and estimate them), then breaking those initiatives down into features (and estimate them), then breaking features down into stories (and estimate them). And along the way mistakes will be made and you will go back up the chain and revise estimates. Then there are additional reviews and redlines and changes in direction mandated by executives.
This can very easily descend into a nearly endless cycle of review and re-estimation. If you’ve never been through this three-month odyssey, what you discover very quickly is that it’s exhausting! And it provides little or no meaningful understanding of the problem domain. It just gives you a starting set of (probably incorrect) estimates. Once that work gets scheduled into PI planning, the estimates will very likely be trivial compared to the dependencies we find in PI planning itself. As a result, you have just wasted three months in an exhaustive exercise to create estimates that are rendered almost immediately irrelevant by the dependencies the we have worked out in the PI planning event. What a gross waste of time! It’s really no different than waterfall. And then, lucky you, can start the ridiculous process all over again for the next PI planning event. Look out George Jetson, I think I’ve found your crazy treadmill. What a bureaucratic nightmare! This is pretty much the state of the art in large organizations today.
SAFe Implementation
What if there were an alternative to this cycle of madness? Imagine if you will, a world where instead of doing that sizing activity, we focus more on breaking the work down to consistently small units (at least as far as reasonably possible) and then just starting the work. And focusing on things that we do have reliable measures for like throughput and lead time. Now if you look at SAFe, Kanban is present throughout. Kanban is in fact a system that is primarily based on measuring cycle time. And given that, we can measure the throughput of our work in terms of cycle time and we don’t need to know the size of objects (or work) at all. In fact, the closer that we can get to everything being uniformly sized the better off we are. So actually, in a peculiar way, if you were to use SAFe with entirely Kanban teams, with associated program and portfolio Kanbans, all of the elements are there to run the system in a purely Kanban fashion with no estimates at all. In fact, one of the foundational elements of Kanban is a #noestimates like emphasis on not using sizing.
Forces
The organization has fallen victim to a painful cycle of estimation and re-estimation
Estimates are used to tell the teams they aren’t productive enough
Estimates are consistently wrong (so rather than blame people, change the system)
Framework Impacts
WSJF only used at the portfolio level
Below the portfolio all work is measured by throughput alone
Forecasting is done using throughput
Benefits
Time wasted on estimation is freed up for more productive work
Improved morale as dysfunctional productivity goals are eliminated
Again, as I stated in the beginning of this article, #noestimates isn’t for everyone. I would only use it with organizations that are frustrated with their heavyweight estimation practices, OR with organizations with a taste for the adventurous.
In summary, with #noestimates we could easily track the throughput in our system. We could eliminate Weighted Shortest Job First because, let’s face it, WSJF is not used by many people and there are some who argue that it has fundamental flaws. Or, with that in mind, you could keep WSJF at the highest levels, perhaps at the portfolio level, but eliminate any sizing below that. Again, these are all options, the beauty is that you eliminate much of the bureaucratic overhead and have the potential to save yourself a lot of time and a lot of pain, to focus on things that are much more important, like the work itself and dependencies, rather than focusing on throwaway work like estimation.
Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. https://bit.ly/2HXCcKD
