Product Backlog Items closest to the top of the Product Backlog should be small enough for the team to be able to complete at least one potentially shippable slice of the product in the next Sprint. As well, they should be ready for the Sprint Planning meeting so that the team can plan its work for the Sprint. To be ready for the Sprint Planning Meeting, each PBI must be estimated. Generally speaking, Product Backlog Items at the top of the Product Backlog are clearer and more detailed than lower ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that at least one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting. Having too many items in the Product Backlog “ready” for the team is considered wasteful over-planning, although generally the top ten items should be in this “ready” state. The value of having a refined Product Backlog before the Spring Planning Meeting is that it enables the Scrum team to focus on the purpose of the Sprint Planning Meeting which is to answer these questions: What will be delivered in the Increment resulting from the upcoming Sprint and how will the work needed to deliver the Increment be achieved? Essentially, what is the Spring goal and what are the tasks needed to complete the goal? Without a ready Product Backlog, the purpose of the Sprint Planning Meeting is difficult to achieve.