You may have an X/Y problem where the symptom is Developers failing to see value in collaborative Sprint Planning. However, the root cause is more likely a disincentive for the Developers to collaborate on a goal-driven Sprint Backlog together.
Analysis and Recommendations
Print Planning and the Sprint Backlog Require a Common Goal
I know this is the wrong behaviour and it is leading to unfinished work.
This is likely a symptom rather than the actual root cause. Based on things you've said and haven't said, it seems likely that the Sprint Backlog coming out of Sprint Planning is lacking a Sprint Goal. A Sprint Goal is required by the Scrum framework, and is what encourages the Developers to collaborate on building a Sprint Backlog rather than "itching to get to work" on their independent tasks.
Incomplete Sprint Goals Imply a Lack of Central Coherence
In addition, "unfinished work" isn't inherently a problem, but it's often emblematic of a team that's focused on "doing all the things" rather than achieving a coherent Sprint Goal. CodeGnome's Scrum Tautology℠ says:
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
Also, consider that you can have a successful Sprint that delivers the Sprint Goal even if you don't complete 100% of the items on the Sprint Backlog. See the next section.
Refine or Redefine What a Successful Sprint Should Look Like
Sprints can be considered successful if they leads to validated learning or process improvement, even if the Sprint Goal isn't met 100% of the time. You may therefore want to discuss the following with the whole team:
- What the Definition of Done is for a Sprint.
- What a realistic percentage of successful Sprint goal deliveries might be. Pro tip: 80% is a good starting point that isn't unrealistic or unachievable, but you can refine it as the process maturity improves.
- Generally revisit what a successful Scrum implementation means for your Scrum Team, the project, and the organization.
In short, move away from 100% completion or 100% utilization as your metric for success. That will provide more incentives for collaboration, and reduce incentives for independent or unplanned work.
Refocus on a Collaborative Sprint Goal
By focusing on the Sprint Goal at the Scrum Team level, rather than defining productivity at the individual Developer level, you will likely reduce the number of unsuccessful Sprint Goal deliveries. This should also reduce the incentives for the Developers to focus on their own work at the expense of the Scrum Team's overall success.
When the Developers see that the plan in the Sprint Backlog requires collaboration between them, they are much more likely to:
- Decompose user stories or Product Backlog item into tasks that can fit within a single Sprint. NB: This is closely related but not identical to the next item.
- Discuss implementation details of Sprint Backlog items to right-size the Definition of Done for all planned work items in a way that helps them fit within a single iteration while still meeting the unified Sprint Goal.
- Build a plan together rather than being incentivized to get to work independently as quickly as possible.
Without that shared understanding of how and why their work fits together, it's hard to see why the Developers would be incentivized to collaborate on a plan. So, building that understanding is foundational to changing the negative outcomes you're collectively experiencing.