The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). - Scrum Guide
The Sprint Backlog represents all the work to be done in the Sprint. It is made up of the Sprint Goal, a set of PBIs, and the developers’ tasks to deliver an Increment at the end of the Sprint.
Sprint Goal
As part of the Scrum Team, you commit in each Sprint to achieve a specific goal.
The Sprint Goal describes why the Sprint work is worth doing and, if you are a developer, it gives you a guideline so that you can determine if the path traveled so far during this Sprint is leading you and your team towards the expected objective.
Remember that if you are using Scrum, you are doing it because you are in a complex environment where you cannot plan accurately based on the unknown. When you create the Sprint Backlog, you know that it is an incomplete plan, that the work will emerge, and it will get consolidated during the Sprint.
Having an objective will allow them to monitor their progress and make sprint plan adaptation decisions frequently. There are many possible ways to reach the same destination. It may be necessary to renegotiate the scope or rethink the approach to solving challenges that may arise.
The Sprint Goal helps you focus on what you want to achieve and gives you the flexibility to achieve it.
At the same time, the Sprint Goal is an aspect that validates the alignment that exists between the Scrum Team and the stakeholders. At the end of each Sprint, the Scrum Team is expected to have built an Increment that achieves the Sprint Goal. That is the commitment, while the work to be done, PBIs and tasks, are a mere way to accomplish that goal.
The Sprint Goal is established in the Sprint Planning and is reached collaboratively between the Product Owner and the Developers.
Sprint Goal Evolution
As time and sprints go by, chances are you'll change the focus of each Sprint Goal.
Initially, your Sprint Goals will be focused on validating the most critical assumptions, those that could make the product fail as a whole. Then, you will go on to validate assumptions of usability, of a specific behavior of the users of your product, of compliance with particular milestones in business outcomes, and, finally, you will have objectives of optimization, performance, and increasingly fine-tuning Sprint PBIs.
Sprint PBIs
The Product Backlog PBIs that are selected for the current Sprint are part of the Sprint Backlog.
This is a set of PBIs that have a certain coherence concerning the Sprint Goal.
They inherit the order they had in the Product Backlog; therefore, it is not the same to work in any of them. One of the situations you want to avoid is that each developer works in isolation in a PBI. For Scrum to work effectively, at the beginning of a Sprint, your team will seek to collaborate on the highest priority PBIs to finish them earlier and then move on to the lower priority ones.
How they decide to collaborate and articulate their work to achieve this type of collaboration is an exclusive competence of the Scrum Team members or Developers. Whatever they use, they will evaluate it and eventually adapt it, Sprint after Sprint.
Sprint Planning
The Sprint Planning is an overview of the tasks that need to be carried out in the Sprint to build the Increment from the selected PBIs and achieve the Sprint Goal.
These tasks last one day or less and are identified by the Team or Developers during Sprint Planning, knowing that many of them will emerge throughout Sprint.
The set of tasks of a PBI represents everything that the Developers identify that must be carried out to bring that PBI to a quality instance identified as Definition of Done. I will tell you a little more about this concept in the Increment section.