Very often you can come to the end of the Sprint and have incomplete features that either can’t be shipped or can be shipped but don't add any value to the end user or Product Owner. If you are given a feature that is going to take weeks, then split it by following this rule.
You are taking on unnecessary risk with a PBI that takes more than 2 days' effort.
Your project could be a very small project spanning just a few weeks/few Sprints or it could be a big project spread across months with multiple Sprint Reviews and multiple teams involved. The massive PBI problem finds its way in all projects. Inspite of all devs being available to work, no blockers, no last minute issues hijacking the Sprint, you could still end up either not pushing things to production or pushing some half-done feature that can't be used.
There are a few steps to take that help avoid this problem:
When you break a monolithic PBI down, try to see if you can break this into shippable features that the customer can use. From a user perspective, it might be better to have a new UI page with only 2 textboxes that actually save data to the DB than have a page with all UI elements but the save button doesn’t work.
If shippable features isn't going to work then another good way of splitting up a PBI is to think about what little pieces of functionality can be demoed to the Product Owner in the Sprint Review.
Say you are doing the Sprint Planning and you see a PBI that says “Sync data with Xero” but not much else. It's been estimated as an 8-day task, which will almost certainly take multiple Sprints. Here are some ways to approach it:
If for some reason you do end up with incomplete PBIs at the end of the Sprint, check out Ending a Sprint - Do you know what to do with partially completed PBI?
❌ Figure: Bad example - This is a monolithic 8-day task
✅ Figure: Good example - The same monolithic task, broken down into 4 smaller tasks which can all be shipped incrementally