Transparency: We all know what is going on.
Inspection: Check your work as you do it.
Adaptation: OK to change tactical direction.

The Product Goal describes a long-term objective or future state of the product. It is a vital part of the Product Backlog, referred to in the Scrum Guide as a commitment. The Scrum Team uses the Product Goal to plan against and maintain focus.

Product Goals were added to the 2020 version of the Scrum Guide. The idea of incorporating this concept was to emphasize the importance of having a longer-term goal than a Sprint Goal. Plenty of research on self-managed, goal-oriented teams shares that goals give focus.

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

As new information is learned, the team must negotiate with the Product Owner regardless of what it is. If the Developers feel strongly about something they think something needs adjusting, they are responsible for communicating the changes to the Product Owner before acting.

Sprints are the Scrum equivalent of an Agile iteration, which is a short period in which a team works to produce an end deliverable.

Within each sprint, there are Scrum inspect and adapt events, also known as ceremonies. These events or meetings are specifically designed to enable critical transparency and inspection.

There are four Scrum inspect and adapt events:

• Sprint Planning
• Daily Scrum (Daily Standup)
• Sprint Review
• Sprint Retrospective

Scrum events create an empirical behavior amongst teams if done in the right spirit. The Scrum Master should ensure the team understands each event's why what, and how. These events also help to create a flow of communication and provide transparency at every level.

According to the Scrum Guide, "The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal".

The Team in Scrum is self-managing, and in order to do this successfully, it must know how it is doing. Every day, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog (Figure 6). It is also common for someone to add up the effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart (Figure 7 and Figure 8). This graph shows, each day, a new estimate of how much work remains until the Team is finished. Ideally, this is a downward-sloping graph that is on a trajectory to reach “zero effort remaining” by the last day of the Sprint. Hence it is called a burndown chart. And while sometimes it looks good, often it does not; this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downward toward completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or find a way to work more effectively while still maintaining a sustainable pace.