I was requested to visit a scrum team that needed some extra help with their planning. That was my personal lesson about letting team to fail in order to learn from their experience.
I joined the teams planning as chicken (= not allowed to speak). Their ScrumMaster asked me to collect some notes and then after the planning to give the feedback about their way of executing the planning session. My first note was that their Product Owner was not present in the meeting. However they had done some preparations and they got prioritized backlog so they started by pulling the stories from it. The stories were not in story format and they were overly complicated as they contained tons of technical details. I noted that these stories must be something their Product Owner has not understood as even I had hard time grasping them (with my 10+ years experience in software development).
After some time the whiteboard was quite full of stories. I thought that these guys must be hyper-productive already though I had some doubt about it. I asked their ScrumMaster what is their current velocity. I could read the confusion from his face as he asked me back "what do you mean by velocity?". Instead of going trough scrum terminology I just calculated their average velocity over last 7 sprints or so. Their average velocity was around 45 story points but their current sprint contained stories that totaled over 150 story points! Obviously the team was about to overcommit.
I raised the fact of overcommitment to the team and challenged them to think it as "lying to Product Owner as he makes business decisions based on the given information". They protested by saying that "we need to show that we are at least trying to make it happen - we are about to have release soon and we must have these features in it". I told them that it is not the teams responsibility to think even about release schedule. Rather the team just gives the effort estimates and Product Owner comes up with release plan. Actually the team had been (micro)commanded & controlled for last few years so they had hard time understanding the self-organization and empowerment that is involved in scrum.
I also asked them if their Product Owner understands the stories. They told me that Product Owner had not even seen the stories! I asked how they have come up with them in first place and they told that Product Owner had given them an epic story (BIG story) and they had asked what does it mean... Product Owner told them to figure it out what it means and thus they had done one sprint with spike "figure it out" and then done second sprint with their own stories that were results of "figuring it out". I realised that their Product Owner was not doing his job and basically the team was responsible also for the ownership. They did not have transparency towards the business side (stakeholders, Product Owner...) and therefore they also felt responsible for release planning.
I told the team that it is their responsibility to not to commit unrealistic schedule but they still did. Finally I had to let them fail - they overcommitted and ... failed ... and hopefully learned the lesson.