These five events are:
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
The Sprint

With frequent inspection, the team can spot when their work deviates outside of acceptable limits and adapt their process or the product under development.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage. The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interactions between them.

“A Scrum Master leads through influence, not authority.”

The 2020 Scrum Guide defines an increment as ”a concrete stepping stone toward the product goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. To provide value, the Increment must be usable…The entire scrum team is accountable for creating a valuable, useful Increment for every Sprint”.

In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed. Without a usable product increment, development teams are delaying the delivery of value and are missing opportunities to get real user feedback and adapt the product to ensure customer satisfaction. On the other hand, incremental releases allow for fast feedback, quicker innovation, continuous improvement, rapid adaptation to change, and more delighted customers.

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.

According to the 2017 Scrum Guide:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

In 2020 it has been changed to:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value for each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

It is important to prioritize the product backlog so that high-value stories are developed first during the daily sprints. The product owner, based on the product vision seen by the stakeholders and clients tries to prioritize the backlog based on:

• Business value
• Definition of ready

One of the main factors to consider while prioritizing a backlog item is to determine its business value and include that value in its definition. The business value is typically a number ranging from one to ten. The higher the business value, the greater the number. The business value is determined after considering several factors, such as:

• Client’s preference and priority in developing the feature;
• End-user requirements;
• Market demand for the feature;
• Levels of competition faced by other businesses developing products with similar features, etc.

The product owner assigns business values to the stories based on the extent of value or financial worth, the story can bring to the business and stakeholders once the product is developed and released in the market.

Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Throughout a good agile project, you should expect to have user stories written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

The Agile definition of done is a collection of criteria that must be completed for a project to be considered “done.” It is essentially a checklist used by Scrum teams to create a shared understanding of what is required to make a product releasable.

To fully understand the definition of done in the context of Scrum, we must first outline two of the key elements in Agile project management:

• Product backlog item: This is a specific improvement that is made to a product. Items can include bug fixes, user stories, and specifications.
• Product increment: This is what is produced at the end of a short development period or sprint. It combines all the product backlog items completed during this sprint.

In specific terms, the Scrum definition of done is a list of conditions that must be met to successfully mark a product increment as complete.

The output of a Sprint is a usable Product Increment. "Usable" means the stakeholders can see the product working as if it were released. The increment is the verified sum of all the Product Backlog Items completed during a sprint, plus all previous increments produced in the current and past sprints. Because of this, the increment needs to be integrated with the ones produced in past sprints. It must be in usable condition, regardless of whether the Product Owner decides to release it or not. The Product Owner is responsible for deciding when to release the Product Increment.

Attendance is not limited to the Scrum Team. When it’s needed, for example, for refinement, the Scrum Team can invite SMEs to provide additional information. This could also include users, the client, or any other stakeholder. This makes the event more engaging, as well as shows you value the opinion of others.

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.

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.

The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and captures the hypothesis that the team wants to test, a goal it wants to achieve, or an experiment to run. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not. This would be unwise considering the core premise of Scrum: we can't create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.

A team might learn that a technology they picked does not perform as expected. Or a key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As issues emerge, changes to the Sprint Backlog may be warranted in order to reach the Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the Product Owner. In short; a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

The Daily Scrum presents Development Teams with an excellent opportunity to inspect and adapt upon their progress to the Sprint Goal and make adjustments to the Sprint Backlog when deemed necessary.