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.
A very effective learning that has come out of many fields of research is that we function well in small groups, specifically groups that range from five to seven people in total. Scrum allows for a slight expansion of that range up to eleven people. This allows for enough people to be together to discuss issues and solve complex software problems with a diversity of skills and experience. As well as avoiding the problem of having too many people that the lines of communication become overwhelming. If the Scrum Team is only four people, then that means that you only have two people doing the tasks in the Sprint Backlog (since the others are the ScrumMaster and the Product Owner). If the team is thirteen or more people then trying to discuss issues, having a focused Daily Scrum meeting, and even building an effective Scrum Team becomes that much harder. The larger the team, the longer it takes to get to a high-performance state.