The NoMeetings Hashtag

This article was removed.
It could easily be interpreted as "mocking" or a "parody" of another hashtag. And it also could be read as a bit "aggressive".
This was not my intention, sorry.

Respons to "Estimation Isn’t Agile" article

This is a response to a blog post written by Craig Buchek: http://blog.boochtek.com/2014/03/23/agile-estimation
I claimed, on twitter, that I had this opinion once as well, but have "changed my mind". He then asked me to write a blog post about my thoughts on it. It's a great idea. So, here it is.
I'm going to quote his blog in here, for easier reading.

I don’t believe that estimation should be part of any Agile practice.

Estimates is a powerful tool. Like any powerful tool, you must learn to use it first.
If you can be agile with or without estimates is an opinion, I don't question that :-)

One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).

The text makes me think that the estimates was delivered as "single point numbers"? Estimates should come with a range and probability. There are lots of ways to do this.
Secondly, I think it's time to talk to this manager. She needs to learn how to use estimates as well. It's not only developers that needs to improve. Solve the root cause first, don't "blame" estimation. Her behavior will not get better if you (or anyone) stop doing estimates.

But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.

The reason estimates are treated as commitments or promises is because how we use them and present and communicate them. If they become contracts is up to you.
E.g. if a bunch of developers take half a day (or a couple of hours or maybe days) to come up with a, probably "accurate", number, no wonder the estimates are treated as commitments. Who wouldn't? They don't know how you came up with that number. They think you are professionals!
Instead, deliver a range with probability. Some say this doesn't work. I disagree. It's not uncommon to hear the doctor say: "It's a 70% chance this operation goes well". You can handle that, everyone can handle that. And then you trigger another discussion, an important one: "What's the 30% risk?"
And, some kind of "promise" must be made. The ones paying us to write their software should be able to know, in advance, roughly how much they're expected to pay and when to get it. Why should we not answer that?

Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.

Yes, agile is about seeking improvement. And doing things better. Improve how you use estimates. Improve how you use your tools. That goes for any tool in your toolbox. As I said, estimates is a powerful tool. Learn to use it. Improve, yes.

Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.

This is a red herring. No project should be on time and budget. Then you're doing it wrong. If you hit time/budget, then you A) Was very, very lucky or B) Adjusted things to hit the time and budget. I'd rather have something great a bit late and more expensive than something bad on time and budget. That is, if budget and/or time isn't crucial. But then, I'd have no problem cutting scope.
This goes for everyone. Put on your customers glasses - they'd probably have no problem if you signal, in time, that the estimate seems to be wrong. It should actually have been a part of the risk discussion before project was started. But still, adjust estimates when you know better. Remember: customer collaboration.

Improved Estimation

To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.

Yes, plans change. Estimates change. Embrace change. Don't lock estimates, keep the conversation going. If you must lock them? Get good lawyers :-)

When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.

I agree. Story points are "lousy" when talking to the ones paying you money to write their software. But this is only my opinion. Some use story points, and they work great. Good for them.

Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.

Don't be optimistic when delivering estimates. This is a common mistake. Why not deliver your "worst" estimate? Who will be sad if you deliver faster? Probably the opposite - they'll be glad! Until they've eventually seen through your "scam" :-) And if your'e trying to "win" a project, or if customer wants to decide if a project is "worth doing" then you should *not* provide your "worst" estimate.
So, start by trying to deliver your estimates with ranges and probability.

What Can We Do Instead?

Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?

I don't think so. If we can, great! Please, let me know! :-)
If managers use estimates to create "predictability", they should improve. Nothing will fix "stupid". Other than stop doing stupid things. Stop estimating will certainly not fix that.

I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.

Agree, but this doesn't exclude estimates. You can do this anyway. But, how do the ones paying us to write their software know (roughly) when the thing you're building for them is "shippable"?

What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.

Agree. Nothing to do with estimates though.

Arguments 

1. Why can’t you just tell us how long it will really take?

Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.

No, you don't *know*. That's why we're *estimating*. If someone takes your estimates for "knowing", rethink how you deliver those estimates. Again, you can't refuse the ones paying us for writing their software the right to get a sense of how much and when.

2. But we have to tell our customers what to expect.

Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.

No, they don't need exact dates. Why do you think they do? Instead, stop delivering exact dates. But they do want to know roughly how much and when. And, estimates comes with a probability.
And everyone should/must have a common understanding on what "done" looks like. No chance of success otherwise.

3. But we have to have messaging about new features.

OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.

I don't understand this point.

4. But we’ve promised these new features to the customers by this date.

Ah, so you’ve made promised to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.

Put on your customers glasses. If someone has promised to deliver something to you and they don't, what would you do?
And, you are actually at it. Don't be optimistic when delivering estimates. Common mistake. Also think about how you deliver your estimate, they should not be interpreted as promises.

Risk

Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.

This is a bit of a confusing point. Yes, estimates are risk. Talk about it with the ones paying us to write their software *before* the risk becomes a problem. Customer collaboration. The risk was *not* to ask for estimates. And don't put trust in them. But that depends on how you deliver them, how you communicate them - customer collaboration.
By the way, who asks for estimates? I've never heard: "We want to buy some estimates!" What they want to know, roughly, is the cost and time. How you provide it is up to you. If you can do it without estimating, good for you! But you can't "blame" the ones paying you to know roughly, in advance, how much and when to expect it. Usually/always you must estimate that.

Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.

Agree. Nothing to do with estimates/no estimates though.
Usually, in all other situations you handle "unknowns"and uncertainties by having margins or "buffers". If you want to buy a TV, you have a "roof" price, but you might still adjust it depending on what you find :-) And if you go on a trip, don't you bring "a little extra", just in case? And if you remodel you kitchen, don't you have margins for certain "unknown" costs that might occur? Well, you should at least. And wouldn't you want to have someone, an expert, to point out these "uncertainties"?
Same thing with software. Talk to the ones giving you money to write their software. Let them know your "unknowns" and your uncertainties. Maybe they want to create "buffers" or margins as well. It's called risk handling. And let them decide later if to use them or not - in collaboration with you.

#NoEstimates is easy

To discuss #NoEstimates (or #BeyondEstimates, I like it more, but let's stick with the "No" in this article) we first must define what an "estimate" is, before discussing it. Otherwise, we are not going to get anywhere in this discussion. And if we have a common definition of "estimate", #NoEstimates is actually quite easy.

The "broad" definition of estimate

First, I'd like to state that "no estimates" doesn't exist. What do I mean? If you merely look at the definition of the word, estimates are always present and always needed. What is this definition then? I take it from Merriam-Webster, I believe it's a reliable source, correct me if I'm wrong. Here it is: http://www.merriam-webster.com/dictionary/estimate. Read it and get back. 

Done? Great! A note, the definition talks about "cost". This is not the "money version" of cost, it's the "cost" of anything. As in the idiom: "Everything comes at a price" (again, not solely money).

Thus, it's used for making decisions. A decision is about choosing among future paths. And whatever we know about those paths, they're estimates! Simple.

That's the "broad" definition of an estimate. Always present, always needed when making decisions. The "world was once flat" argument is not relevant or equivalent, it's more like "do something has to be, or made, of a roughly round shape to roll?" Yes, it's the definition of "rolling". No one has ever thought anything else.

Thus, "no estimates" - in this definition - doesn't exist.

The "developer" version

But that's not how a developer would define an "estimate". And it's the "developer" version of "estimate" that #NoEstimates is trying to address. In my opinion, I must add.
What is this definition then? I'll give my version:
"The formal delivery of the estimated size of a task/item that is to be done".
I.e. the "process" that goes along with when someone asks a developer to "estimate". One, or usually a team, of developer(s) sit down and play some "planning poker" or whatever he/she/they do to come up with a figure or range.
This process is sometimes waste. This is what #NoEstimates is trying to address.
Note, I said "sometimes". It's not always waste. Sometimes it's actually very useful (depending how it's done, of course - improve!).

And that's why #NoEstimates is easy! Just start thinking! Question wasteful behaviors.
I.e. ask: "In this specific situation, is estimates (as the 'developer version' above) useful?"
An example: someone asks "Before you start working on this item/task, estimate it first!" Sometimes this is not needed. Just start working on it might be the most valuable thing to do. Whatever that reason might be. One example could be that everyone (even the one asking) has an "innate" feeling that the "size" of the item/task is not "2 hours or 1 week, it's something in between" and in this specific situation it's sufficient knowledge to know it's worth start working with it.You could call it an "implicit" estimate. Making it explicit would be better? Yes (see my "final thoughts" in this article). But, we are talking about the "developer" definition of an estimate here.
Hence, that estimate would probably not even be used for anything. Except maybe to use it as a commitment (a promise)?

There are a lot of examples of when estimates can be wasteful. This was just one example.

Some do this already. Some are already doing #NoEstimates. 

Thus, "no estimates" - in this definition - exists.

What #NoEstimates is not

#NoEstimates is not about "Everyone in the entire organization should probably stop estimating!". Because everyone in the organization has their own version of what "estimate" is. Depending on their role. For some, all their estimates is probably useful. And #NoEstimates is not trying to question those estimates.

A final thought

Let's play with a thought. A silly thought perhaps, but still a thought.
What if "the ones giving us money to write software" could estimate software work themselves? What if the "estimation process" then turned into a conversation with those providing us money instead?
"You may say I'm a dreamer, but I'm not the only one" :-)

TL;DR

As a developer I estimate all the time: "Should I write an if-statement or a switch-case? Should I create an abstract class or an interface? Where should I put this code? Should I write a test? Should I use this framework or that framework? Will this or that code be more readable? What will be most maintainable? What will have the highest performance? What will be easiest to write? What will take shortest time to write? etc etc etc"

Hence, "no estimates" doesn't exist. But it's not those types of estimates #NoEstimates is trying to address.

#NoEstimates is not for me, part II

I've written some posts about the #NoEstimates topic. I found it very interesting. And very "giving" and learning. But I've come to the conclusion that it doesn't exist. Why? Let me explain.

But first, this is my definition of "estimate", the transitive verb: http://i.word.com/idictionary/estimate

"Estimates are waste"

Yes, they might be. Anything can be waste. Easy: Stop! Don't do stupid things on purpose. Nothing new or special about that. #NoAnything would apply, or maybe more specific #NoWaste might be a more appropriate tag? Nothing more to say about that.

"Explore alternatives to make decisions in software development. That is, make decisions with 'no estimates'"

Why would you want to do that? Why find alternatives to something obvious? Can we make decisions without meetings? Sure. But why? Meetings are a great way to make decisions. Making decisions with other people is the best known way to make decisions. Why explore alternatives to that? Same thing with estimates. Are there alternatives to the wheel? Yes, you can use an airplane or a boat. But the *wheel*, it's unbeatable, one of the first thing mankind invented, and it's still the best. Why explore?
And, a decision - by definition - is to choose between one or many future paths. And whatever we say about the future - it's an estimate. Can't argue that. Thus, "no estimates" is not applicable when making decisions. At least not in software development.

Update:

If "exploring alternatives" is what we like to do, with the purpose that it's better to have *more* alternatives, then I don't get the "no estimates" either. Estimates are great knowledge when making decisions, why remove that alternative? Why remove any alternative?

"Not getting the question of 'how much/when?' at all"

This I can get. Deliver often and more important: deliver something valuable often. But this is true even when you choose to do estimates. Nothing to do with "no estimates". But if we work this way, the question of "how much/when?" might not come as often (or at all)? Sure. But still. Someone has to pay for the work getting done. That person wants to know, roughly, what he/she is expected to pay. And he/she wants to know in advance. Can't question that. Unless you plan to work for free, this is always true. Thus, "no estimates" doesn't exist. 

In the "smaller loop" (when someone already knows, roughly, what the expected cost is and "the work" has started) you might throw away estimates. This is the only valid point of "no estimates" as I can see. I've done similar things before (without even knowing that "no estimates" existed). But it's close to my first point above. Don't do stupid things. If no one requires you to do estimates - don't! And if this is the only valid point of "no estimates" then it's not much to "hang in the Christmas tree" (as we say in Sweden when something is of not much value).

"Focus on value instead of costs or estimates"

Yes, of course. But this has nothing to do with estimates or "no estimates". You can do both. At the same time. And value is tightly coupled with cost. At least in software development.

"Forecasts is not estimates"

No comments on that. Learn English, maybe?

Final words

I might still be convinced though :-)

#Estimates by Example

This is a follow up on my previous post #NoEstimates by examples. This post is probably less interesting since we all know more or less how to do estimates. This post is mainly for my own "documentation", a  historical note of my own thoughts at the time - a blog post! ;-) There are also a lot of "established" techniques for doing estimates. I'm not claiming to know any of them, and I might have got names mixed up or wrong. Maybe I should learn them. But I'm focusing on this blog post right now...

I've stated before that I have really not a problem working with estimates. I think we might be able to work without them, I'm willing to try and explore that. But I think we also should improve the way we use estimates. This is only true for me and the company I work for - we need to improve this, I'm not saying you have to.

I'm not gonna describe in detail how we work with estimates, let's just say we're not using them in a really good way. In essence, we think we're agile, but we haven't really got the "customer collaboration" thing...

The approach (improvement)

For me it's all about creating options. In almost every situation. If you only do that you're halfway there. Let your customer (or whatever) have options to choose from, let them be in charge on which path to choose (in collaboration). Don't just fall in to same old habits.
In my previous post I only stated that one option is to do estimates. But even choosing this path have options in itself. This is where we need to improve.

The "easy" approach

This is mainly: do a fairly quick estimate, maybe pad it arbitrarily (by whatever experience you have) and then put a price and make a schedule based on it.
How you then handle the erroneous in this estimate against your customer is up to you. Maybe you have a fixed price and some penalties in the contract. Or if you keep the price (and/or time) open, and the customer still pays if going over budget. Or maybe some combination of the two, I don't know.
This could also be called the "rough feeling" estimate.
On the upside, the customer doesn't have to pay a lot of money for us doing a "great" estimate.
If customer chooses this option, really make sure you declare that this is *very* uncertain. If you succeed with this declaration or not is also highly uncertain...

"Level of probability"

This is one I really like, but I also think it's the one that will take most time to produce, and requires some "heavy" estimation work. I haven't done it myself, but I've applied similar approaches.
It's a way of illustrating that estimates are not about *knowing* but that it comes with some level of probability.
Think of it as: "When is it 0% change of delivery and when is it 100% change of delivery? When does it start to *not* be 100% and 0%? What is our best guess (most likely)? When is it 50%?" You then have relative probability diagram, showing something like this:

The diagram can look very different than this, it's just an example, it's up to you to create this. The "curve" is created by keeping the area under the curve the same before and after the 50% mark. Together with the customer you can then choose at what level of probability we want to aim for. And we have visualized that we aren't 100% sure, we *know* it's likely not going to happen, because we (the customer) have chosen the probability level, it's part of "the deal". "We feel a 70% probability is ok, then we probably (with 70% chance) can deliver after X weeks/days/hours/whatever." It's the area under the curve that gives us the likelihood. Thus, to get e.g. 70% likelihood we have to pick somewhere after the 50% mark. And e.g. 20% (why choose that?) is pretty close to the likelihood of 0% (looking at the graph).
I think it's a great tool. 

On the downside I think it will take some time to produce.

The Triple Constraint triangle

This is actually really not an option per se. It can (should?) be applied regardless of option chosen above.

This is a great way of showing that "You can't have it all, at least one side must be kept open. Which one (or two, or all) should be left open for adjustment?"
It's also great to show customer that reducing the length of any side will probably reduce the overall quality in some form. I think it's a great illustration for having discussions.

Others

There are lots of more options to create (and choose from). Please, let me know if you have any other ideas.

Now it's up to our customer to decide what to choose, what they are most comfortable with.

#NoEstimates by examples

The best way to learn something is by examples. You know when you read documentation, you always skip to the examples. Examples are a great way of creating understanding. You can never have to many of them either (well, maybe not entirely true...). Gojko Adzic has, for instance, written an entire book on how to specify requirements by example: Specification by Example.

Anyway, I thought I would give an example on how I understand the #NoEstimates approach. I'm not saying this is the "right" way (is there?) or it's the only way. I'm not saying this is the shared understanding on how #NoEstimates are done - this is my interpretation. I'm gonna be honest as well, I haven't done this in practice. But I would certainly be able to try it, and I probably will.
Enough of disclaimers, here it goes.

The example

This is actually a quite real example (regarding the customer's need). I'm working on a similar project right now.

A customer wants to update the design for their public web site. Their existing one looks quite old and needs a visual update. They don't expect the update to generate more or other types of visitors. They just feel they want to make it more attractive and look "newer". I don't blame them for that.

As a customer I think the first question that comes to mind is "How much would it cost? Roughly." And it's a fair question. I would want to know that as well, if it was my site.

The way we do this (and I think it's the usual way) is to stall that question and ask "Let's look at what you have in mind and what can be done first." We then arrange some meetings (e.g. workshops) to create a better understanding of what the customer is expecting. The customer even accept to pay for it. But when the workshops have been held, the question still remains: "Roughly, how much is it?"
We respond to this by gathering some developers (that have done similar things before) and estimate each page type and other things we've said in the workshops. Basically going through the "product backlog" and estimate each "item". Then we sum them up, pad the sum with some time for meetings and demos and some corrections (changes and bugs) and other "unknowns" - and there you have our estimate (and price). Then we have a meeting with the customer to go through the project plan, the schedule, our estimate, the cost etc.
You all know the drill.

An alternative (the #NoEstimates) way

This is how I understand #NoEstimates. And this is an approach I could use. Again, I'm not saying this is *the* way to do #NoEstimates - it's how I understand it. I might be all wrong...

We could respond "This looks quite big. It's actually impossible for us to know the exact cost and time for this. We could do an estimate, but the only thing we know for sure is that the estimate will be wrong. So, I have an alternative suggestion. Let's see what you think of it. If you like it or not. Otherwise, we can do an estimate if you like that approach better?"
"I think what you feel right know is uncertainty. I believe there are something you don't know right now that you want to learn? My suggestion is that we start with perhaps the start page or maybe some other page you are most concerned about. Do you think it's worth to just do that page and see how long it takes and how much it is? Then we can stop or continue, based on what you know then. Is it possible to create a budget for just that little thing? Then you don't have to spend a lot of money up front. We'll create this in small steps instead, or how large steps you like. But let's decide how large steps you want to take when you know more about all this. What do you think?"
There's probably a lot more questions we need to answer here. It's impossible for me to write down every possible question a customer might have. But one instinctive question would probably be "How much do you think we should budget?" My answer would be: "How much are you willing to spend to gain this knowledge? The more you spend the more knowledge you will get. But we won't spend the entire budget if isn't needed. We'll stop when you have the knowledge you need. And whatever we produce it will be usable, how small or big it is."

It might work, it might not. But at least we have let the customer decide which path to choose. They know what they have chosen. And we have declared that the "estimate" path is just as uncertain as the other. Or maybe even more uncertain?

"But I REALLY want to get a sense of what it will cost!"

My answer would be: "Ok, your biggest problem here seems to be that you want to know what this will cost. How can we help you learn what all this will cost? First, I must say that you probably don't want all the things you think you want today. But there are ways to help you with this. One way is we can take some time to estimate all this. Another alternative is that we can start working on something with biggest risk or highest value or whatever you are most concerned about. Then we can see how long that takes and we then have a feeling for what all the other things will probably take. What do you choose?"

There might be other alternatives as well, but it all boils down to create options. Let customer decide what he/she likes the most - don't just fall back on what you have always done.

#NoEstimates is not for me..?

I'm really curious about the #NoEstimates movement, but I can't really get my head around it. What is it? Do we even need to know what it is..? I'm not sure.
Is it: "Don't estimate in any part of the project - from idea to implementation"? Or is it: "Use estimates in a way that is useful for us"?

I don't know. I've written some posts about no estimates, but I've realized I've only stated the problems, not any solutions that correlate to no estimates. Not in a sense that they are about *no* estimates, at least. I've only stated how to do estimates differently.

My issue

The root cause for me with how estimates are used is that they become promises and commitments. The problem with that is that these things easily creates pressure. Pressure that may lower creativity, new ideas, quality etc. You know how it is... I don't know what your issue with estimates are, but this is my biggest problem.

One "solution" (but not related to #NoEstimates)

I think we need to change. We - developers/managers ourselves - are the main reason estimates are treated as commitments and not what they really are: *estimates*. Note that what I will write next fits me, it doesn't necessarily have to fit you or your situation.

This is how I've been doing, and how I think many are doing:
When a customer (or whoever, in the end, are paying us) wants to know how much it will cost (or how long it will take) they usually don't what to know in detail what it will cost, they just want a rough sense. Because, they don't really care what it will cost in detail. But even so, this is how we usually respond: "We'll have to get back to you about this. We will look at it and get back to you next week with an estimated cost." And next week we come back with the figure (and usually a gantt chart): "We have looked at this and we estimated it to 1140 hours with the cost of [1140 x hourly cost]."

What is the problem with this approach? If I where to put on my customers shoes, how can this behavior be interpreted as anything else than a commitment? Someone (we) have put time to come up with a very exact number. My feeling would be: "These guys/girls really seem to know what they are talking about! How can they know this? Let's not ask, they seem professional. This is great!"

So, how should we do then? Well, this is only my opinion, I'm not saying this is the right way. But it could work.

Give them that *rough* feeling they are really asking for - straight away!: "I think this is about a couple of months of work. But it's just a rough feeling." They might actually be fine with that answer, and it can't as easily be interpreted as anything else than an estimate. And if they want a more "detailed" estimate, they have to ask for it, and then we can say: "Yes, but it will probably not be more accurate than my initial rough feeling. But if you want to pay us for doing that, we can do it. But whatever we provide, it will probably still be as uncertain as my initial feeling."

I don't know, it might work. But is it NoEstimates? No, just estimates done differently.

Other approaches

I've read other approaches, under the #NoEstimates flag, to come up with an answer to the question of "How much/How long?"
But, as we can't know in advance what something will cost or how long it will take - if we respond and how ever we came up with a respond: it's an estimate. Period. That's why I don't get NoEstimates. Can we provide an answer to "How much/How long?" without guessing the future? I can't even imagine that. That's why NoEstimates is not for me, at least not right now. But I will still follow the movement :-)