Scrum Guide: Roles, Events, and Artifacts

Introduction

This is the third article in a series of articles on Agile. In the previous articles, we started diving into the world of Agile by exploring the core values and principles that underpin this approach. We’ve examined how Agile helps teams adapt to change and succeed in uncertain conditions. Now it’s time to delve into one of the most popular and effective Agile methodologies — Scrum. In this article, we’ll break down the key elements of Scrum so you can understand how this framework helps teams work more efficiently and productively.

Understanding Scrum

To gain a deeper understanding of Scrum and its importance in the Agile world, it is essential to look at its core elements, history, and the philosophy that underpins it.

What is Scrum

Scrum is a lightweight framework that helps people, teams, and organizations create value by offering adaptive solutions to complex problems. This framework requires creating an environment in which:

1. The Product Owner organizes the work needed to solve complex problems in the Product Backlog.

2. The Scrum Team turns selected work into a value-carrying Increment during a Sprint.

3. The Scrum Team and stakeholders inspect the results and make adjustments for the next Sprint.

4. The process is repeated.

Scrum provides enough structure so that people and teams can integrate it into their work, while allowing the necessary practices to be added for optimization according to their specific needs.

Scrum, as described in the Scrum Guide, includes three key roles: Product Owner, Scrum Master, and Developers. These roles ensure a balance between management, support, and execution of work, helping the team achieve their goals. The Scrum Team participates in four main events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events occur within the Sprint, which serves as a container for all other events and allows the team to manage their workflow by creating three artifacts: Product Backlog, Sprint Backlog, and Increment.

Origins of Scrum

The name “Scrum” was borrowed from rugby, where it refers to a collective scrum in which a team works together to move the ball forward. In the context of project management, Scrum works similarly: the team collaboratively moves the product forward, continuously improving it at each stage of development.

Scrum was developed by Ken Schwaber and Jeff Sutherland in the early 1990s in response to the need for a flexible approach to software development that would ensure rapid adaptation to change and high productivity.

Empirical Process, Values, and Principles in Scrum

Scrum is based on empiricism, which asserts that knowledge comes from experience and decision-making is based on observation. This approach is grounded on three pillars — transparency, inspection, and adaptation. Transparency allows all participants to see the real state of the project, inspection helps regularly evaluate and adjust processes, and adaptation enables a quick response to changes and improvements.

The core values of Scrum — commitment, focus, openness, respect, and courage — help create an environment where the team can effectively achieve its goals. These values foster open communication and collaboration within the team, which supports successful work and the resolution of complex challenges.

Scrum operates in short cycles called Sprints, during which the team incrementally delivers value. The feedback received during the Sprint allows for regular inspection and adaptation, ensuring continuous improvement of the product and processes. The Scrum Team is responsible for creating a valuable Increment, which is inspected and adjusted in collaboration with stakeholders for future Sprints.

Scrum Team

A Scrum Team consists of one Scrum Master, one Product Owner, and Developers. This team works as a single unit, without subgroups or hierarchical structures, ensuring that all participants work together and focus their efforts on achieving the Product Goal.

The Scrum Team is cross-functional, meaning all team members have the necessary skills to create a valuable product in each Sprint. Additionally, the team is self-organizing, allowing them to determine who will perform tasks and how, thereby fostering autonomy and accountability for results.

A Scrum Team is usually small, with a team size of up to 10 people, allowing it to remain flexible and maintain effective communication. If the team becomes too large, it is divided into several smaller Scrum Teams, each working with the same Product Goal, Product Backlog, and Product Owner as the original team.

The Scrum Team is responsible for the entire product creation cycle: from stakeholder engagement to validation, maintenance, operations, experimentation, research, and development. The organization empowers the team to manage their own work, enabling them to focus on tasks and maintain a steady pace throughout the sprints.

The entire Scrum Team is responsible for creating a valuable and usable Increment in each sprint. Each of the three specific roles within the team plays a key part in the successful achievement of the team’s goals.

These aspects of Scrum Team organization help maintain its efficiency, flexibility, and ability to adapt to change, ultimately leading to the successful achievement of the Product Goal.

Scrum Master

The Scrum Master is responsible for implementing Scrum within the team and the organization, promoting an understanding of Scrum theory and practice. They support the team and the organization in adopting Agile principles by facilitating the effective adaptation of the Scrum methodology.

In addition to these responsibilities, the Scrum Master must have well-developed soft skills for coaching and mentoring the Scrum Team and others in the organization. They help improve team dynamics, provide guidance, and assist team members in finding solutions independently to enhance overall performance.

The Scrum Master coaches the team in self-organization and cross-functionality, facilitates the creation of high-value increments, removes barriers to progress, and ensures that Scrum events are productive and timely.

The Scrum Master assists the Product Owner in effectively defining the Product Goal, managing the Product Backlog, planning in complex environments, and facilitating stakeholder engagement.

The Scrum Master leads, coaches, and mentors the organization through the Scrum implementation process, promotes an empirical approach to solving complex problems, and removes barriers between stakeholders and the Scrum Team.

To be effective, the Scrum Master adopts various roles such as servant leader, facilitator, coach, manager, mentor, teacher, impediment remover, and change agent, depending on the situation. These roles enable them to address the diverse challenges the team faces and support continuous process improvement.

This multi-faceted approach allows the Scrum Master to remain a key element in the successful implementation of Scrum, providing the team with support and guiding them to achieve their goals.

Product Owner

The Product Owner is one person who is responsible for maximizing the value of the product through effective management of the Product Backlog. They ensure that the Scrum Team’s work is aligned with the Product Goal and prioritize tasks to deliver value to stakeholders and users.

The Product Owner articulates the product vision and goals, ensures the Product Backlog is transparent and understandable, and is responsible for creating and organizing the Product Backlog items. While they may delegate certain tasks, the Product Owner remains accountable for the results and the value the product delivers.

To be successful, the entire organization must respect the Product Owner’s decisions. These decisions are reflected in the content and order of the Product Backlog items, as well as in the Increment that the team demonstrates during the Sprint Review.

The Product Owner assumes various roles such as visionary, partner, customer representative, decision maker, experimenter, and influencer to effectively manage the product and maximize its value. Misunderstanding the Product Owner role, such as viewing them only as a writer of user stories or a project manager, can lead to a distorted perception of their responsibilities.

Developers

Developers are responsible for creating any aspect of a usable Increment in each Sprint. They participate in Sprint Planning, create and maintain the Sprint Backlog, ensure the Increment meets the Definition of Done, adapt their plans daily to meet the Sprint Goal, and support each other in professional development.

The role of Developers is not limited to programming; it encompasses any product work, including design, testing, and delivery. Specific skills may vary depending on the type of work being done, but the focus always remains on creating a complete and quality product.

Developers also participate in events such as the Daily Scrum, may mentor, coach, and train other team members, especially through practices like Pair Programming, which promotes skill sharing and learning.

Developers, along with the rest of the Scrum Team, must adhere to Scrum values such as commitment, focus, openness, respect, and courage. These values play a key role in resolving conflicts, accepting new ideas, maintaining focus, committing to the Increment, and respecting other team members and their contributions.

Scrum Events

Scrum events are designed to create regularity and minimize the need for other meetings that are not prescribed by Scrum.

The Sprint acts as a container for all other Scrum events, ensuring that they are conducted within a unified and consistent structure.

Each Scrum event provides a formal opportunity to inspect and adapt Scrum artifacts, which is critical to maintaining transparency and improving processes.

To reduce complexity, it is recommended that all Scrum events be held at the same time and place whenever possible.

Sprint

The Sprint is the heartbeat of Scrum, where ideas turn into value. It is the central event in Scrum, encompassing all other events. The Sprint allows ideas to be converted into value through short and regular work periods.

Sprints have a fixed duration of no more than one month, ensuring short iterations for feedback and minimizing complexity and risks. A new Sprint begins immediately after the previous one ends.

No changes are made during the Sprint that might jeopardize the achievement of the Sprint Goal. The quality of work must be maintained at a high level, the Product Backlog is refined, and the scope of work selected for the Sprint may be refined or revised with the Product Owner as needed.

The Product Goal is the long-term objective reflected in the Product Backlog and guides the work of the Scrum Team. The Sprint Goal is a short-term, flexible goal for the Sprint that provides focus and alignment, helping the team work together.

An empirical approach plays a key role during Sprints, allowing the Scrum Team to learn through experience and continuously improve. Progress is often tracked using tools such as burn-down charts or cumulative flows, but these cannot replace the importance of empirical learning.

A Sprint can be canceled if the Sprint Goal has lost its relevance. This decision can only be made by the Product Owner.

Sprint Planning

Sprint Planning initiates the Sprint by defining the work to be done. The entire Scrum Team is involved in creating a plan that aligns with the Product Goal.

The Product Owner prepares the team in advance to discuss the most important elements of the Product Backlog and how they contribute to the Product Goal.

The key questions discussed during Sprint Planning are:

• Why is this Sprint valuable? The Product Owner suggests how the product can increase its value, leading to the creation of a Sprint Goal that reflects this value.
• What can be done in this Sprint? The Scrum Team, with the support of the Product Owner, selects items from the Product Backlog for inclusion in the Sprint, refining them as necessary.
• How will the selected work be accomplished? Developers plan the necessary steps to turn Product Backlog items into a completed Increment, breaking tasks into smaller parts if needed.

The result of Sprint Planning is the creation of a Sprint Backlog, which includes the Sprint Goal, the selected Product Backlog items, and a plan for their execution.

Sprint Planning is time-boxed and takes a maximum of eight hours for a one-month Sprint, with proportionately less time for shorter Sprints.

Daily Scrum

The primary purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed to keep the team on track.

The Daily Scrum is a 15-minute event that takes place every day at the same time and place throughout the Sprint. Developers choose the structure and techniques for the meeting themselves, focusing on creating a plan of action for the next day. If the Product Owner or Scrum Master is actively working on items from the Sprint Backlog, they may participate in the Daily Scrum as Developers.

The Scrum Master ensures that the Daily Scrum takes place and teaches the team to stay within the 15-minute timebox. However, the responsibility for conducting the meeting lies with the Developers.

This meeting improves communication, identifies obstacles, facilitates quick decisions, and helps avoid the need for additional meetings. Developers can adjust their plans not only during the Daily Scrum but also meet throughout the day to discuss and adapt the remaining work.

The Daily Scrum allows the team to assess progress and make necessary adjustments to optimize the likelihood of achieving the Sprint Goal. This continuous adaptation is a central element of the Scrum process.

Sprint Review

The primary purpose of the Sprint Review is to inspect the results of the Sprint and identify the necessary steps for adaptation. It ensures alignment between the Scrum Team and stakeholders on progress towards the Product Goal.

The Sprint Review is a working session, not just a presentation. The meeting is time-boxed to a maximum of four hours for a one-month Sprint, with proportionally less time for shorter Sprints.

Participants in the Sprint Review include the Scrum Team and key stakeholders invited by the Product Owner. During the meeting, the Scrum Team discusses what was completed and what was left unfinished, and Developers share the successes, challenges, and solutions they encountered during the Sprint. Developers demonstrate the completed work and answer questions about the Increment.

The whole group discusses the next steps, including adjustments to the Product Backlog based on new opportunities, market changes, or feedback.

The outcome of the Sprint Review is an updated Product Backlog that reflects the likely items for the next Sprint, as well as any necessary adjustments to leverage new opportunities or address emerging issues.

Sprint Retrospective

The Sprint Retrospective aims to improve the efficiency and quality of the Scrum Team by analyzing the past Sprint and planning improvements.

The Scrum Team discusses how the Sprint went in terms of interactions, processes, tools, and adherence to the Definition of Done. They analyze what worked well, what problems occurred, how those problems were solved, and identify any factors that may have led the team off course, exploring their origins.

The Scrum Team identifies the most significant changes needed to improve performance. These improvements are prioritized and may be added to the Backlog for the next Sprint.

The Sprint Retrospective is time-boxed to three hours for a one-month Sprint, with proportionally less time for shorter Sprints.

By the end of the Sprint Retrospective, the team commits to implementing specific improvements in the next Sprint, ensuring continuous adaptation and improvement of workflows.

Scrum Artifacts

Scrum artifacts are created to increase transparency and provide a clear basis for inspection and adaptation, ensuring that key information is understood uniformly by all participants.

For each artifact, there are specific commitments:

• Product Backlog: Linked to the Product Goal, which guides the overall development and purpose of the product.
• Sprint Backlog: Linked to the Sprint Goal, which defines the focus and goal of the current sprint.
• Increment: Associated with the Definition of Done, which ensures that the work meets the required standards before it is considered complete.

These commitments reinforce the empirical approach and support the values of Scrum, helping the Scrum Team and stakeholders stay aligned and focused on progress.

Product Backlog

The Product Backlog is a dynamic list of tasks needed to improve the product and is the sole source of work for the Scrum Team.

The process of refining the Product Backlog involves detailing and breaking down items into smaller tasks, which increases transparency and ensures that items are ready for selection during Sprint Planning. This process is ongoing and can be performed at any time during the Sprint.

Developers are responsible for sizing the Product Backlog items, with the Product Owner providing guidance on trade-offs.

The Product Backlog is closely linked to the Product Goal—the long-term objective that guides the work of the Scrum Team. The Product Backlog contains items that contribute to this goal. The Scrum Team focuses on achieving one Product Goal before moving on to the next.

The Product Goal defines the future state of the product and serves as a guide for planning and prioritization within the Product Backlog.

Product Goal

The Product Goal is a long-term objective that provides context and direction for the Scrum Team, guiding the work outlined in the Product Backlog.

The Product Goal serves as the commitment associated with the Product Backlog, ensuring that the team’s efforts are directed toward a clear and shared objective.

As the Scrum Team learns and iteratively improves the product, the Product Backlog evolves to better align with the Product Goal. The Goal remains transparent to all stakeholders, helping to maintain the team’s focus.

During the Sprint Review, the team and stakeholders evaluate progress toward the Product Goal, using these findings to inform subsequent Sprint Planning and maintain alignment with the Product Goal.

Sprint Backlog

The Sprint Backlog consists of the Sprint Goal, selected Product Backlog items for the Sprint, and the plan for creating the Increment.

The Sprint Backlog provides a clear and up-to-date picture of the work planned for the Sprint, making it highly visible and essential for tracking progress during the Daily Scrum.

The Sprint Goal serves as the guiding objective for the Sprint, providing flexibility in executing the work while maintaining the team’s focus and alignment.

Each Increment represents a specific step toward achieving the Product Goal, with all Increments adding value to the previous ones and being fully integrated with each other. Work must meet the Definition of Done to be considered part of an Increment, which can be delivered at any point during the Sprint, not just at the Sprint Review.

The Sprint Backlog is a dynamic tool that is updated and adapted as new information is acquired during the Sprint. If unexpected changes occur, Developers collaborate with the Product Owner to adjust the scope of work while maintaining the Sprint Goal.

Sprint Goal

The Sprint Goal is the primary objective of the Sprint, providing the Scrum Team with a clear focus and encouraging collaboration around a common purpose.

The Sprint Goal is set during Sprint Planning and added to the Sprint Backlog. While the goal remains unchanged, the scope of work can be adjusted in collaboration with the Product Owner if complexity or requirements change.

An effective Sprint Goal should be clear, achievable, and substantial enough to keep the team focused and ensure incremental value delivery.

The Daily Scrum focuses on inspecting progress toward the Sprint Goal, emphasizing its importance and ensuring the team remains aligned with the goal throughout the Sprint.

Increment

An Increment is a specific step toward achieving the Product Goal, building upon previously completed work to provide incremental improvements to the product.

Each Increment builds on the previous ones, must be thoroughly inspected, and ready for use to deliver real value.

Multiple Increments can be created within a single Sprint and may be delivered to stakeholders before the Sprint Review if they are ready.

Work is only considered part of an Increment if it meets the Definition of Done, ensuring consistency and quality.

Definition of Done (DoD)

The Definition of Done is a formal description of the quality standards that an Increment must meet to be considered complete and ready for release. The DoD serves as a commitment by Developers to ensure these criteria are met.

The DoD provides transparency and a common understanding of what “done” means, ensuring that everyone knows the standards that must be met for an Increment to be considered releasable.

The DoD may include mandatory organizational standards, but the Scrum Team can add additional criteria specific to their product. If organizational standards are not available, the team creates an appropriate DoD.

Examples of Definition of Done:

For a mobile app:

• The app has passed all stages of testing on major platforms (iOS and Android).
• There are no known critical bugs.
• The user interface (UI) conforms to the design guidelines.
• A code review has been performed, and all feedback has been addressed.
• The app has undergone performance testing.
• The app has been deployed to a test environment and verified for functionality.

For a blog article:

• The text has been edited and checked for spelling and grammar errors.
• The article has undergone fact-checking.
• All necessary images and links have been inserted and formatted.
• The post is published and optimized for SEO.
• The article has been tested for display on mobile devices.
• The post has been announced on social media and included in the newsletter.

Compliance with the DoD ensures that the Increment is complete and meets high-quality standards. This helps the team focus on creating work that meets the necessary criteria before it can be considered “done” and ready for release.

Agile Learning and Practice

Understanding the key aspects of Scrum is crucial for successfully implementing Agile methodologies. To further develop your skills and apply Agile practices across various projects, we recommend using our comprehensive tool Agile Coach Pro:

Agile Coach Pro provides tailored guidance and continuous learning opportunities, helping you master Agile practices like Scrum, Kanban, and XP. By leveraging this tool, you can stay up-to-date with the latest industry trends and confidently apply Agile methodologies to achieve outstanding results in your professional endeavors.

Conclusion

Scrum is a powerful framework that enables teams to work more efficiently, creating value in the face of uncertainty and change. Understanding its key elements, such as roles, events, and artifacts, helps Scrum teams achieve high performance and ensure continuous improvement. Scrum’s empirical approach and values create a foundation for successful collaboration within a team, which ultimately leads to a quality product and user satisfaction.

By mastering Scrum, you will take an important step towards becoming a successful Agile practitioner. This framework not only improves the development process but also fosters a culture of collaboration and continuous learning in your organization. Continue to deepen your knowledge and put it into practice to fully realize the potential of Agile and achieve outstanding results.

In future articles, we will take a closer look at the practices of another well-known Agile framework, Extreme Programming (XP).