… the Scrum Team has a well-defined Product Backlog and is convening Sprint Planning to define the current Sprint. The Development Team gives a forecast of the anticipated delivered Product Backlog Items (PBIs) to the Product Owner, but the team members must define how they plan to develop them.
✥ ✥ ✥
In order to understand whether the team can complete a PBI in the Sprint, they need to understand the PBI in detail. Breaking a PBI down into Small Items helps the team more deeply understand the work necessary to bring a PBI to Done. This is design work that flows into the Scrum itself. You can’t afford to shed any of this design work. But the team has only incomplete understanding of the work necessary at the beginning of the Sprint, and the work is likely to grow as more insight emerges.
The Development Team needs a basis upon which to self-organize to accomplish the Sprint Goal. Frequent and accurate feedback at the Daily Scrum on the work remaining are essential for the Development Team to manage the dynamics of development.
The Development Team needs a starting point for measuring progress against the Sprint Goal. Of course, the ScrumMaster and Product Owner are interested too. But it’s the Development Team that actually creates the Product Increment.
Create a work plan for everything that the team must accomplish to meet the Sprint Goal. The team usually subdivides this work into Sprint Backlog Items (SBIs). These items may represent tasks that the team must complete, or intermediate building blocks that combine into a deliverable, or any other unit of work that helps the team understand how to achieve the Sprint Goal within the Sprint.
✥ ✥ ✥
The Development Team creates and owns the Sprint Backlog and only they can change it  (see Developer-Ordered Work Plan). The essence of creating the Sprint Backlog is the detailed design of the PBIs so that anyone in the Development Team can explain how they will accomplish the Sprint Goal . The Sprint Backlog helps provide a mechanism of expression of the how of development, and helps the Development Team remember its design decisions. But a Sprint is by definition time-boxed. Therefore, the Development Team must consider its velocity to create a Sprint Backlog that it thinks that it can finish within the Sprint. Use patterns of velocity, such as Yesterday’s Weather and Updated Velocity, to help the team determine how much they can put in the Sprint Backlog.
A precise Sprint Backlog helps the Development Team to remember all detailed work they need to do. The Developers decide the order of the Sprint Backlog and should keep it ordered to optimize the chances of meeting the Sprint Goal. The contents of the Sprint Backlog can change during the Sprint. As Developers learn more about the difficulty of the work, they might add or change SBIs. They could remove SBIs, or even split or combine them. The dynamic nature of the Sprint Backlog makes it necessary to do incremental re-planning as a major activity of the Daily Scrum.
The Sprint Backlog provides the basis for tracking progress  (Sprint Burndown Chart) and for making status visible (Visible Status). At the Daily Scrum, the Sprint Backlog helps Developers decide what they will work on next. While there is no formal ordering of the Sprint Backlog, there is an ordering in the sense that certain SBIs depend on the completion of others. The fact that the Development Team Swarms on PBIs also affects the ordering, but it’s up to the Development Team how to manage it. However they manage it, the Development Team must understand the dependencies among the SBIs so they can order their work and have an accurate picture of status; see Dependencies First.
The Developers should make the Sprint Backlog transparent to all stakeholders with an Information Radiator such as a Scrum Board, to increase transparency. One must be careful that people outside of the Development Team will not use this transparency to micro-manage the team. The Sprint Burndown Chart and Scrum Board digest Sprint Backlog progress into more visual Information Radiators.
 Ken Schwaber. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004, p. 50.
 Ken Schwaber and Jeff Sutherland. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. Chichester, UK: Wiley, 2012.
 Ken Schwaber and Jeff Sutherland. The Scrum Guide. Scrumguides.org, http://www.scrumguides.org (accessed 2 November 2017).
Picture from: https://pixabay.com/en/painter-paint-cans-brush-paintbrush-1246619/ (under CC0 license)