This chapter provides a high-level overview of the Scrum framework. Later chapters provide a more in-depth look at each concept and element.
Scrum is a refreshingly simple, people-centric framework for organizing and managing work. It is built on a specific set of foundational values, principles, and practices. Organizations typically add their own unique approaches to the Scrum framework, creating a version of Scrum that is uniquely theirs.
Every Scrum effort consists of one or more Scrum teams, each made of three Scrum roles: product owner, ScrumMaster, and the development team. Other roles do exist in organizations that use Scrum, including managers. The Scrum framework only defines the roles that are specific to Scrum, not all of the roles that can and should exist inside an organization.
Product owners decide which features and functionality to build and the order in which to build them. Learn more about the product owner in Chapter 9.
Consider taking a Certified Product Owner class from Innolution for comprehensive training on the product owner role.
ScrumMasters act as coaches and facilitators to Scrum teams, ensuring that the team and the rest of the organization obtain optimum results from the Scrum process. The ScrumMaster role is discussed at length in Chapter 10.
Innolution offers in-depth ScrumMaster training through its Certified ScrumMaster course.
The development team is a diverse, cross-functional collection of all of the types of people needed to design, build, and test a desired product. Refer to Chapter 11 for more on development teams.
For an in-depth look at how to be a productive member of a Scrum team, consider taking Innolution’s exclusive course: Working on a Scrum Team.
Scrum Activities and Artifacts
The figure below illustrates most of the Scrum activities and artifacts and how they fit together. Key elements of the diagram are discussed in the sections that follow.
Scrum teams try to always do the most valuable work first. The prioritized list of this work is called a product backlog. For new products, this backlog initially contains only those features required to meet the product owner’s vision. For ongoing product development, the product backlog might also contain new features, change requests, defects, and more. The product owner, with input from the stakeholders and development team(s), is ultimately responsible for maintaining the product backlog, which evolves and changes throughout the project.
The activity of creating and refining the product backlog items, estimating them, refining them, and prioritizing them is often known as grooming. For comprehensive training in agile estimating and planning, we recommend the course, Agile Estimating and Planning.
Every sprint begins with sprint planning. During sprint planning, the team and product owner agree on a sprint goal. The team then selects a subset of high-priority items from the product backlog that can be completed during one sprint, assuming the team works at a sustainable pace. This subset of work is captured in the sprint backlog. For more details on sprint planning and how teams select a sprint backlog, see Chapter 19.
Sprint execution is the period of time during which the task-level work is performed by the development team to complete the features committed to during sprint planning. In this context, done means that there is a high-level of confidence that all of the work necessary for producing good-quality features has been completed. See Chapter 20 for more details on sprint execution.
Every day of the sprint, the development team meets for a 15-minute daily scrum, where team members share with each other what they did yesterday, what they will do today, and any obstacles they are facing. This meeting is also called a daily stand-up, because team members are encouraged to stand to keep the meeting brief.
In Scrum, we refer to the completed work at the end of the sprint as a potentially shippable product increment. Done, or potentially shippable, means completed to a high degree of confidence and being of such quality that the work could be shipped to end customers at the end of a sprint. Being potentially shippable, however, does not mean the results will actually be delivered to customers. Shipping is a business decision; potentially shippable is a state of confidence.
The sprint review occurs at the end of every sprint and is a time to inspect and adapt the product. The sprint review is intended to foster conversation about the just-completed functionality among the product owner, ScrumMaster, development team, stakeholders, customers, and anyone else interested in the outcome of the sprint.
The sprint retrospective occurs at the end of every sprint and is a time to inspect and adapt the process. In the spirit of continuous improvement, the ScrumMaster, product owner, and development team come together to discuss what is and is not working with Scrum and associated technical practices.
After the sprint retrospective, the entire cycle begins again, starting with the next sprint planning session. The next chapter provides a description of the core principles upon which Scrum is based.
View all Scrum training offerings from Innolution.