During this meeting the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Sprint Backlog and it provides guidance to the developers on why it is building the Increment. Having set the Sprint Goal and selected the Product Backlog Items for the Sprint, the developers usually start by designing the system and the work needed to convert the Product Backlog into a working product Increment.
By the end of the Sprint Planning, the developers should be able to explain to the Product Owner and Scrum Master how they intend to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
After defining the context, let's consider 9 Sprint Planning anti-patterns in detail.

Sprint Planning Anti-Patterns of the Scrum Team
1. The Scrum Team has irregular Sprint lengths. This happens when the Sprint length is adapted to the size of the tasks or the Sprint Goal. Instead of changing the Sprint length to accommodate the Sprint Goal, the Scrum Team should invest more effort into sizing tasks in the right way.

2. The Scrum Team takes on Product Backlog Items that do not meet the Definition of Ready. It could be that the Scrum Team has not created at all a Definition of Ready that Product Backlog Items need to match before becoming selectable for a Sprint. A simple checklist, that a user story must meet before being accepted into an upcoming iteration, is enough to increase the quality of user stories and the general way of working as a team.

3. The Sprint commitment is not a Scrum Team decision. This could happen when just one of the developers, the tech lead for example, represents the rest of developers in the meeting. According to the Scrum Guide, the whole Scrum Team needs to participate and collaborate, otherwise Scrum values will suffer.

Sprint Planning Anti-Patterns of the developers
4. The developers are not forecasting future velocity by combining recent velocity with team's capacity for that Sprint, therefore they may take on too many tasks. The team should instead take into account public holidays, Scrum ceremonies and other meetings, new team members and team members quitting, just to name a few examples.

5. The developers are not demanding any capacity to address technical debts and bugs. In case the Product Owner ignores this practice and the developers accept this violation, future product delivery capability will decrease.

6. The developers do not work collaboratively on a plan to deliver on its commitment. In some cases the senior developer assigns tasks to the individual members who they feel should complete the work. Rather than pushing tasks to individuals, team members should be allowed to pull tasks into their in-progress work, this improves communication and skills transfer.

Sprint Planning Anti-Patterns of the Product Owner
7. The Product Owner is absent. In Scrum, the Product Owner is part of the team and responsible for driving the value of the product for the customer through the work of the developers, therefore it is important that the Product Owner actively works with the team throughout the entire Sprint to answer questions and avoid misunderstandings and rework.

8. No Sprint goal is defined. If the Sprint backlog appears a random assortment of tasks, it may be a signal of a weak Product Owner who listens too much to stakeholders instead of prioritizing the product backlog appropriately. According to the Scrum Guide, the Product Owner is the sole person responsible for managing the Product Backlog and this includes ordering the items in the Product Backlog to best achieve goals and missions. No one can force the developers to work from a different set of requirements.

9. The Product Owner tries to include some last-minute Product Backlog Items that are not ready yet. It is true that only the Product Owner can make such kind of changes to ensure that the developers are working only on the most valuable tasks at any given time. However, if the Scrum Team is practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. In case those episodes happen frequently, it indicates that the Product Owner needs help with ordering the Product backlog and team communication.

Anti-patterns in Scrum are habits that are frequently exhibited but overall ineffective or maybe even harmful, so it is important to recognize and eliminate such behaviour.

Source:
This post was inspired by https://dzone.com/articles/scrum-19-sprint-planning-anti-patterns