… 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 a PBI can be accomplished in a given Sprint, you need to understand the PBI in detail, which is facilitated by breaking them down into Small Items to estimate. This is design work that flows into the Scrum itself. You can’t afford to shed any of this design work. But this understanding is incomplete, and must evolve 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 needs to be accomplished in order to complete the Sprint Goal. The items of this work plan are called Sprint Backlog Items (SBI). These items may be tasks that the team must complete, or intermediate building blocks that can be combined into a deliverable, or any other kind of items that helps the team understand that the Sprint Goal can be achieved 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 is able to 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 expects to be able to finish within the Sprint. Use patterns of velocity, such as Yesterday’s Weather and Updated Velocity, to help determine how much can be 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 course of the Sprint. As Developers learn more about the difficulty of the work, they might add or change SBIs. SBIs could be removed, or even split or combined. 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: moodboard, GettyImage, image-id: 104329689. Needs permission