Yesterday I promised to give some concrete examples related to what I call #NoOthers. The first one will be #NoEstimates.
What #NoEstimates should/could be
Example #1
Product Manager : “We have plenty of things to do on the product. There are many new features to add and there are also a couple of really embarrassing defects that we should address too. I need to know how long each of those things is going to take so that I can balance defects with new features in the schedule.”
Dev#1 : “Well…It ain’t easy to estimate bug fixing time before we get into it. As far as I can tell right now no bug solving ever took more than 3 days, but we can do some stats if you really need to make accurate forecasting.”
Dev#2 : “The thing is that we are not confident at all with the estimates we give you. For the smaller things we can have some interesting enough statistics based on what we already did in the past…but for user stories like foo or bar the scope is way too big.”
Product Manager : “I understand that you can’t give me accurate estimates…but I really need to know when we are going to start working on baz. At least sales people need to know.”
Dev#2 : “We can try to split foo and bar into smaller user stories so that they can fit into the stats we have, but maybe we could just consider working on baz right now if it’s that important?”
…
Example #2
Customer : “I need to know how much it will cost me to have this product, and when it will be done.”
Project Manager : “Of course. But allow me to suggest that maybe your real need is not the one you think.”
Customer : “What do you mean?”
Project Manager : “Well, as far as I understand the product you want to build, you definitely need to get to the market as soon as possible.”
Customer : “Who needs not?”
Project Manager : “Yes. So let’s first try to focus on a core set of features that will allow you to get to the market quickly. We really want to extract the features that compose the very minimum product here. Then we could improve the product by adding the other features as described in the specs…or other features if needed. Does it make sense to you? ”
Customer : “It totally makes sense…but I still don’t see how much it will cost us in the end.”
Project Manager : “It will cost you the amount of money you want to put into it! Of course for the minimum product we will provide you some kind of cost estimate after breaking the selected features into small pieces of work, but for the rest you will be able to stop when you want to.”
…
What #NoEstimates sometimes is / How it is perceived
Product Manager : “We have plenty of things to do on the product. There are many new features to add and there are also a couple of really embarrassing defects that we should address too. I need to know how long each of those things is going to take so that I can balance defects with new features in the schedule.”
Dev#1 : (thinking) He wants estimates, let’s give him estimates! Maybe he wants some random numbers to fill in a lottery ticket after all “No more than two days for each of these bugs IMO. foo is pretty big : I think of 7 or 8 days of work. bar looks easier so I think it won’t take long.”
Dev#2 : “Not sure about bar : nobody has touched this part of the product for a while. I don’t think we can estimate that upfront… Hmm… What is the real purpose of this story again?”
Product Manager : (thinking) Here we go again! NoEstimate bullshit! She doesn’t want to commit herself with an estimate and will argue about the purpose of every single piece of user story “Come on! You guys are incredible…”
…
No Others
I must admit those (almost) fictional pieces of dialog are a bit cliché, but they outline a key difference between what #NoEstimates is and how it is often perceived :
- #NoEstimates is a hashtag that gathers people who want to try and find an alternative to using estimates as a tool. It really is a #NoOthers concept in the sense that we need to understand everybody’s needs to find the best suited tool / way of working together (and we think that estimates might not be that tool).
- #NoEstimates is perceived as a rebellious community of developers – others – who do not want, or who simply can’t, understand what business people – us – need.
- #NoEstimates can be used as a banner to wave in front of product/project/whatever managers – others – who do not, or simply can’t, understand what dev people – us – need.
More will come on this subject…
Great post! Love examples, they give clarity.
In Example #2 I can see some problems though. First I would say it’s estimates done better, and not really no estimates. But that’s fine.
Second, I think one will have a “fight” with customer what the MVP is. I mean, the customer probably will say that everything in her “requirement list” should be in the MVP. But let’s be positive, and say it can be done (with impact mapping or something), you still have to answer the “when?” question upfront.
Third, this approach might even be more expensive for customer. Why? Because when the MVP is delivered she has to take another round with the board (or whatever) to fund the other features she wants (but not part of the of the MVP) and have a budget for those. This process is often quite time consuming and costly. And how should she fund them? She doesn’t know what to budget. Thus, it might be better to know – upfront – how “big” all the features are. Even though all of them probably won’t be built at all. But it helps them decide if it’s worth investing in what features. And it helps them decide. And not have this funding/budgeting/planning process over and over again.
For most organizations I actually think this is true. And then, a NE approach in most cases is not applicable.
Hi Henrik! Thank you for taking the time to leave such a detailed comment.
I won’t deny that I took really big shortcuts in those examples. My goal was basically to describe an atmosphere more than to describe precise situations. So yes, maybe sometimes it’s estimates done better. Actually I’m fine with that : we tried to find a better tool than estimates, but we did not. It’s ok : let’s try to use them better then, to at least reduce their negative impact when they have one.