This is a good question. I'll answer from the perspective of someone with 30 years experience with a decade as a dedicated project manager in all areas except software development but recently stumbled into the area software development unintentionally. Regardless of the methodology being used across your team and what it is called, at the end of the day development projects are the same as any other in the business sense that objectives are to be met within competing constraints of time, budget, and quality -- and while projects execute the business continues to move and evolve and has a good chance of injecting changes into your project. Therefore, it is necessary to set and commit to objectives and timeframes and to be able to provide updates on a frequent basis and when asked. I don't recommend the answer to queries be some form of "if you ask that question it shows your ignorance and you need to be trained".
That being said, in my experience what makes time estimations in software development particularly challenging is that development projects entail a lot of unchartered territories. The technical definition of a "project", according to the Project Management Institute's Project Management Body of Knowledge, is that a project must be unique. Yet, the far majority of "projects" in IT are mere re-executions of previously devised blueprints & designs and implementation run books. In software development, we have frameworks and various genericized design patterns that make a lot of the development re-usable but still, the core of each project is completely unique.
In addition, most development projects entail integrating with other systems and how quickly that can be done is a big guess. I am working on a project right now that my original time estimates were based on the assumption that the 4 systems that I need to interact with programmatically would have API's, and it turns out none do. In addition, one of the systems is cloud hosted, and my organization has policies that prohibit the work being done. Who could've predicted that?
As discoveries are made that put timeframes in jeopardy it is important to well communicate why the delay has arisen, why it couldn't be foreseen, etc.
I've also been through being told the timeframe given wouldn't work and make it happen much "quicker". Another variation is being given a boat load of changes to inject into the development without also being afforded the additional time. There is a law in physics that says matter cannot be created or destroyed, and this comes to mind because it seems to me that time cannot be created out of thin air either. Accelerating the development will likely have a negative impact on the release quality, the supportability of the product, and/or the future evolving of the product.
Requests about the schedule should be answered in general business terms. "Yes, we are on track to meet the timeframes previously committed, and there are no issues brewing that put that in jeopardy". Requests to add significant scope without more time, or to simply accelerate delivery, should be some form of "we can do that, but just so all are aware that inherently carries risk of bugs because much of the development time is done to be proactive so as to not introduce bugs and also to test comprehensively." When they respond with "so just test faster", that gets a response that explains development testing does not entail idle time and can be accelerated without introducing some risk of missing defects.
In summary, I am simply suggesting that all developers -- not just the leads, scrum master, or project manager, be prepared to discuss their tasks in a business context and to have discussions on changing project parameters by making aware the trade-offs that would result.