Do we estimate in Scrum? Yes!

A really smart and experienced colleague says we should not estimate. And that in Scrum particularly, we should not estimate.
Now, to get into the deep inner-workings of Lean and Continuous Flow...well, I am not going to go there today.
As a minor point, I will say that the latest Scrum Guide to me says we estimate in Scrum.  Especially 'work remaining', both at a Sprint level, and at a 'release' level (although the guide says 'goal' instead of release -- I won't go there right now.)
But let's assume we really need a real explanation of why, not just 'the bible says'.
Where do we start to explain? I started at one place, and I kept going backwards. I kept asking myself "Yes, but why is that so?"  So, having gone backwards enough (at least, enough for me), I will go forwards in the ideas with you.
When the Duke basketball team plays UNC tonight, who is responsible for winning?  Just Mason Plumlee? (the big center for Duke, possibly their best player, a senior).  Coach K?  Well, they are too...but the whole Team is responsible. They win or lose as a Team.  Coach K only says that 1 million times each season. They win or lose as a Team.
OK, in Scrum, who is responsible for success?  The Team.
We have this saying: The PO is the single wringable neck. True, but possibly mis-leading. Yes, if the Team is not producing enough benefit over cost compared to other options (or just not enough period), then in Scrum, the PO has to call it and 'stop the madness'.  Do the right thing. And stop the Team completely, or start on another product.
It does not mean that the PO is the sole person responsible for success.
The whole Team is mutually responsible for success.
To customers, success always means delivering earlier, delivering fast. You, as a customer, always want it yesterday.  It is a key component of success.
Now, customers understand it takes some time, and they always say they want 'everything'.  But they need a solution now, so time also is always a critical factor.
So, we are always caught in this dilemma...do it faster AND give us more. It is a tension, it will always exist.
There are lots of stupid things we can do with this tension. Here are some classic ones:

• Death March!
• Unsustainable pace (the less immoral version)
• Cut the quality to make the date
• Give up
• Pretend like time is unimportant

Occasionally 'give up' is a responsible option, for example, when it is obvious our product will be too late to the market.
But usually the responsible thing is for the whole Team to manage through the tension.
In terms of specific trade-offs of stories (does it go in this release or the next release -- is often the question), typically the PO makes the call.  But based on all the input and work of the Team. The Team together is successful or fails.  The Team together works on impediments, for example, to improve their velocity.  The Team together must make the date.   (I don't want to mention any wonderful products that were late to market and failed. Do you really need me to do that?)
So, the whole Team needs estimates.
How much work will X be? (X could be a story or a whole release.)  And, as I assume you know, we use Story Points and Velocity in agile. (I won't explain them here.)
So, what's the problem?
Well, there are many problems that we have to deal with. Some were mentioned above (Death March, for example).
Next problem.  Many many Team members have seen estimates be used, over and over again, to just beat them into unsustainable pace. They have just been used irrationally and stupidly. They often have an immediate visceral reaction. Please be considerate of that. It is based on real (bad) experiences.
Next problem. As soon as we do estimates, some stupid manager (yes, there are a few stupid managers out there) starts to think that the estimate is perfect.  It NEVER is. That's why we call it an estimate, doh-doh head! (Speaking to that manager right now.)  I bet there is even a stupid manager in your firm, at least stupid on this subject.  Fix him or her.
So, in Scrum we do lots of things to manage the estimates, manage the tension. Some are:

• Remove impediments to increase velocity
• Re-estimate
• Learn more
• Break down the stories more, and move part of that work to later
• Try to harness the good change more (eg, learning, and ... did we mention fixing impediments?)
• Don't let the bad news get 'better' with age (one version: "no bug survives the sprint")
• Learn to estimate better (tends to happen, to some degree, naturally with time)
• Estimate as a Team (gosh, to me it was assumed, but I guess I better make it explicit...this does help a lot, especially with time)

We also have to be careful what we say when. Example: We do the initial release planning. We guess at the Team's velocity. Should we tell a 'stupid' manager the initial date (with some guessed at buffer) immediately?
Maybe not!  Maybe we wait a couple of sprints (this is how long the waterfall estimates used to take...it might be ok)...wait, find out the real velocity of the Team, and then propose a (more accurate usually) date range.
So, we need to use estimates in Scrum. In a professional way.
There is good stress and there is bad stress. Manage the tension in such a way that it becomes good stress for your Team. It won't be easy, but then most good things require some work.
***
Was this convincing to you? Could you use these ideas to explain to the Team why they should want estimates?  Could this help your PO? Comments please.