The battle I’m sick of fighting
Hey all – I know it’s been forever since I’ve posted. I feel like I should have went back to the just showing up post a few times. As some of you know I’m getting my masters degree (done in May) and have switched companies (a few times). Life is crazy, as many projects are. On a side note – I’m working on a research project on women’s involvement in the Agile community (to complement #WomenInAgile), so stay tuned over the next couple months for more details on the results and how you (even if you’re not a woman) can participate in a survey to help — I promise it’s less time-consuming than the State of Agile survey.
Anyway back the reason for this post. I’m going to rant a bit. <rant> I am so sick of having estimating battles. Sure #noEstimates can work if the team understands what they’re doing, has good leadership, a decent product definition, and oh so many other things that can affect estimation and delivery. I love the ideas of cycle time, smaller chunks and limiting WIP without having to put a number on it, but in my practical experience it can be harder than estimating and management doesn’t go for it. For most teams, especially starting out together on a new product, with a new product owner, with BIG ideas and who wants ALL the things (you know the ones I’m talking about), #noEstimates is not viable. End of story — to be discussed in another post of when I get torn apart in the comments or bombarded with #noEstimates success stories and tweets, I’m sure.
So let’s skip that “to estimate or not to estimate” battle for now and say I won you over and the importance of estimation gets through – or you’re just curious about what I have to say and decide to continue reading for the mere entertainment of my passionate and slightly annoyed tone. The next obstacle often turns into the points versus days battle – that’s another old friend. The purpose of this post isn’t to say what is right or wrong – my consultant answer (if I were a consultant) is, “it depends”. Again, it depends on the team, the org, the product, the complexity etc.
I just find this battle at every company I’ve worked at and it chooses unsuspecting (sometimes) times and avenues to rear its ugly head. Honestly I don’t care if you estimate in baboons or dassies (I just got back from South Africa) as long as you’re estimating and comparing work items to one another utilizing past experience– because realistically most teams need to estimate in some form. Even if they don’t NEED to, most management want some type of metrics to relate to predictably versus a promise of having it done. They want a plan, a good guess, an estimate with something to back it up — remember trust is built on prior interactions and history. Once teams can start providing this consistently, showing their predictability and transparency, and earning a reputation and trust, then talk to me about #noEstimates. Until then, measure something, estimate something, and adjust as necessary (and I guarantee adjustment will be necessary). The act of estimating is something I won’t budge on and will advocate and battle to the end (even though it can turn into an earworm that just won’t get out of your head, i.e. now)
agile cycle time delivery estimate ideal days MAOL metrics no estimates predictability purpose of estimating relative estimates relative estimating research project scrum story points team maturity transparency women in agile
10 Responses
Absolutely love this post Natalie and could not agree more on every point. This battle is one that most Agile Coaches / ScrumMasters / etc…face and is exhausting. Love the fiery tone of the post as well.
Hi, Natalie,
I’ve found value in not taking requests for estimates at face value. That’s not to say that an estimate should not be forthcoming, but that it’s worth digging a little deeper for the need. My go-to question is “What decision depends on this estimate?” The answer to this question helps me understand the precision, accuracy, and cost of estimating that is appropriate for the situation.
– George
Great insight, George. It is always good to ask “why” we’re doing something and what depends on it. Cost of delay is something I find comes into play frequently with estimates or lack thereof. No estimates are not always good to take at face value, especially as the team is learning and maturing, but they should be worth something if only that we need to work to be able to take them at closer to face value and what is the cost if we don’t/can’t or better yet, can! Thanks for reading!
I understand how you feel, and I hate, hate, hate labeling opinions as “dogma”, because so many people do so very lazily. Unfortunately, an attitude of “nothing you say will change my mind” doesn’t help.
I, too, want to build trust among gold owners, goal donors, and producers. I know that estimating provides a way to get there, but too many people estimate as a matter of course, get into fights over those estimates, and this wastes precious energy. I adopt the opposite approach: throw away estimates and focus on delivering high value sooner until the team matures together, then estimates become much more useful as finer control over where and when to invest. Fewer petty arguments. Less micromanaging.
Yes. Many people distrust it. That’s frustrating for me, too. Perhaps as frustrating as it is for you. This alone doesn’t make estimates a good idea. It makes estimates a necessary evil. As long as we’re exploring features looking for the most valuable parts and building them first and ruthlessly eliminating obstacles to making them available to paying customers, the estimates just don’t matter. They’re icing on the cake. Many people find out that they just don’t like the icing as much as they thought they did.
In spite of all that, if you find value in estimating and teaching others to estimate, then I’d never suggest that you stop. I do ask, however, that you not say things like, “The act of estimating is something I won’t budge on and will advocate and battle to the end.” More dogma doesn’t help us deliver better software. We agile-minded folks get accused of this enough as it is.
Thanks for the comments – yes it is harsh but I did state that it was a rant. We each have our own ‘dogmatic’ things, if that is what they are being called, I’d rather call them convictions, and estimating is one of mine. I appreciate your opinion and taking the time to comment.
What seems to be missing from the estimates or no-estimates conversation is the legitimate needs of those funding the development of value from the project. The business, any viable business, operates on a balance sheet basis. Even a research based software business.
Money is exchanged for value. The business’s legitimate need to have some level of confidence in knowing when that spend will be returned with a measurable value.
It appears that many in the no-estimates community are unaware of how business works.
The processes of estimating the cost, schedule, and the probability that the produced capability will deliver the expected value in exchange for the investment is the basis of decision making in microeconomics. This is an “opportunity” cost decision process. “What value am I willing to risk, in exchange for some future value?” The answer to that two-soded question can only be answered with an estimate of both the cost and the returned value.
In non-probabilistic terms it’s ROI = (Value-Cost)/Cost. Change that simple equation to one where each variable is a random variable, then provide multiple choices and Real Options is the next step. There are further steps, but business can operate with these two.
Estimating is not for the developers, it’s for those providing the money for the developers to produce value.
As George suggests “it depends.” But this “depends” has a simple framing assumption.
“How much are you willing to loose if you don’t know both the probabilistic cost and value to some acceptable confidence level?”
If that value is below your threshold then estimating provided little value. If that value is above your threshold, estimating is required for microeconomics reasons alone, ignoring governance, cash flow, marginal value returns, and other financial aspects of writing software for money
I might also suggest, as an afterthought, that those saying we focus on value over cost, need to talk to those writing the checks for that value.
Both Value and the Cost of that value are part of the ROI assessment of all business decision making. Both are needed, both play equal roles in the decision process, since that “opportunity cost” discussion is the basis of microeconomics of software development.
See http://herdingcats.typepad.com/my_weblog/2014/07/economics-of-iterative-software-development.html for an overview
I agree, we need to remember that estimates are larger than the team. As much as we don’t want to think about funding being a constraint and instead constraining scope, it is a long journey. Every situation is different but this conversation is one that comes up very frequently and should be considered when thinking about how much value can be provided – both to the customer and to the stakeholder/organization who has the checkbook.
[…] and test that estimated (remember, when we estimate we’re often wrong but it’s a good practice for most teams) or other work that can pop in. I’m not going to get into estimating defects and tech debt […]
[…] we estimate all our work, we need to discuss the difference between our new feature velocity (used for roadmap forecasting) […]