TL;DR
Don't plan or start work that won't fit into the Sprint. Decompose any remaining work further until it fits within the current Sprint, or let the team figure out what backlog items to descope for the remainder of the Sprint while still meeting the Sprint Goal. Then reallocate any excess slack to process improvement.
Any work that remains incomplete at the end of a Sprint is re-estimated and placed back onto the Product Backlog as future work to be re-prioritized. The Scrum Guide says:
All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
So, unless work is related to the Sprint Goal, or to continuous process improvement, tail-packing work into the Sprint is often a wasted effort. Don't do that.
What's Missing: Goals and Slack
Am I missing something?
Yes. What you're missing is the focus on a Sprint Goal. The Scrum framework requires a central coherence to tie all the work of the increment together.
The goal of a Sprint isn't to complete lots of tasks. The goal of the Sprint is to deliver the Sprint Goal!
Once you shift your focus to a coherent goal, the tail-packing issue you're experiencing is surfaced as waste (in a Lean sense) and quite likely a variant of the 100% utilization fallacy. It also highlights that much of the team's work is not cross-cutting enough, and that your team itself may not be sufficiently cross-functional or self-directed enough to address continuous improvement issues when they truly have nothing else to do.
"Idle" time is very rarely actual waste in the Lean sense. Downtime and slack are essential to agility, and provide essential opportunities to improve tooling, testing harnesses, equipment, or other aspects of the team's process and infrastructure. Skimping on slack is often one of the key predictors of suboptimal performance for queue-based frameworks, and Scrum is no different.
Alternatives to Tail-Packing
It's worth mentioning that in 20+ years of Scrum and other agile practices, I've rarely seen excess slack to be a real, long-term problem for teams with a healthy inspect-and-adapt process. Instead, I've generally seen teams that struggle with having a reliable product delivery cadence improve by adding slack and avoiding tail-packing.
Rather than tail-packing your work, the team should generally plan to gently undershoot their capacity for the Sprint. This will generally result in a modest amount of slack that can be repurposed to evergreen quality and process work, or (as is more often the case) simply result in better quality as team members repurpose excess slack for code (or product) reviews, testing, documentation, and Sprint demos.
Some teams also put evergreen backlog items into the Product Backlog so that Sprints that radically undershoot capacity can peel off additional work. You can also work with the Product Owner to move up Backlog Refinement to decompose additional work that can fit into the remaining time box. In cases of truly egregious amounts of excess slack, the remaining time can be spent on workshopping better estimation techniques to improve Sprint Planning and Backlog Refinement in the future.
Another way to avoid tail-packing is to increase swarming, self-direction, and cross-functional activities within the team. Rather than tasking work out to individuals, working as a group on features rather than tasks often yields better results. It puts more eyes on the work, and creates a better environment for collective ownership of the increment than task-oriented assignments.
In Scrum, the whole Scrum Team is responsible for meeting the Sprint Goal. They aren't just responsible for their own tasks! If the team has not yet met the Sprint Goal, but aren't saying to one another:
I've finished X earlier than tomorrow's Daily Scrum; can I help you finish Y today?
then you don't yet have a mature agile team. If there's work remaining on the Sprint Backlog, it's usually best to complete all current work-in-progress before starting a new work item. Even when not, the whole team should be coordinating dependencies for the Sprint Goal at least daily, which makes what work should be done next self-evident when discussed as a group.
Use the Retrospective
The Sprint Retrospective is where this issue ought to be discussed as a team. Discussions about how to estimate capacity better, how to collaborate more effectively, or how to optimize the teams process should be done at least once per Sprint in order to provide a tight feedback loop.
If you have extra time within your current Sprint, use some of that slack time to examine your processes and discuss alternatives. Time spent improving your process pays large dividends over a long-running project, and even small improvements paid early on can represent a significant return on investment through the magic of compounding efficiencies.
