Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint. The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs. The Product Owner relies on the team to estimate if they are small enough. If the PBIs are not small enough then large problems can arise. Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review. Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint. Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint. A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively. One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand. The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint. This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.