an Agile champion. The Scrum Master is accountable for the Agile team happiness and why this is important. They remind the Agile team members of the benefits and value of the Agile approach whenever needed and encourage the right behaviors from the team members. For example, the Scrum Master may remind team members to be honest and transparent in their communications. The Scrum Master facilitates all meetings, including daily meetings. They coach the Agile team members in self‐management and cross‐functionality; help the team focus on creating high‐value increments that meet the Definition of Done; and facilitate the removal of impediments or roadblocks and obstacles to help the team progress and remain efficient in completing Sprints, ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. A Sprint is a short, timebound cycle within which team members complete an increment of work to deliver products the customer needs based on whatever is most important to the customer at the time.
Delivery Team (Developers)
The Delivery Team Members own the “how.” They complete product tasks during Sprints. They are the individuals in the Agile team who are committed to creating any aspect of a usable Increment in each Sprint. They create a Sprint Backlog, a specific, focused list of tasks determined by the Delivery Team to complete an increment that guides their Sprint/increment work. An increment is a product deliverable, usually a small portion of the overall product. The Sprint Backlog is a specific, focused list of tasks determined by the Delivery Team Members to complete an increment. The team has total authority on the exact approach to get their work done, estimate how long work will take, create their schedule, and manage their own time. They are a cross‐functional, self‐managing group of autonomous individuals collectively possessing all the skills necessary to complete the Sprint backlog. In Scrum, Developers can be business developers, user experience researchers, customer experience specialists, mechanical engineers, lab technicians, doctors, nurses, carpenters, marketers, researchers, scientists, quality assurance specialists, and more.
We will review these roles, responsibilities, and options throughout the book. In Chapter 7, Implementing Agile Auditing: Deciding Your Approach and Your Agile Audit Project Roles, we will address the different roles of Product Backlog in an auditing context. In Chapter 9, Implementing Agile Auditing: Planning Agile Audit Engagements, we will apply Scrum concepts in an audit context, including the Product Owner, Scrum Master, Delivery Team, documents, and activities. Remember, Agile and Scrum are frameworks, and adaptations are expected; some Scrum implementations include additional roles.
Scrum Artifacts
Scrum Artifacts represent work value. Following are the three Artifacts, or documents, created in the Scrum framework (Sutherland and Sutherland 2014). Each of the three Scrum Artifacts has a corresponding commitment to drive focus and alignment. This commitment gives the teams a much better focus on the specific goals. The Artifacts are:
1 Product Backlog (see Chapter 8, Implementing Agile Auditing: The Audit Planning Process). The Product Backlog is a list of requirements and features for a project that is managed by the Product Owner in order of business priority. Product Backlogs include estimates on business value and development efforts. The commitment for Product Backlog is Product Goal.
2 Sprint Backlog (see Chapter 9, Implementing Agile Auditing: Planning Agile Audit Engagements). The Sprint Backlog is a specific, focused list of tasks the Delivery Team believes it can complete in a Sprint. It is created by the team members, using a pull approach to complete an increment. Contrasted with a push approach, where an input is pushed into a cycle in hopes that it can be used as it is pushed, or can wait until it is needed, a pull approach pulls inputs into the process or production line on demand, as needed. The push approach may result in excessive production and unused work, while the pull approach is quick and efficient. The commitment for Spring Backlog is Sprint Goal.
3 Increment. An increment is production output at the end of a timeboxed Sprint. The commitment for increment is the Definition of Done.
We acknowledge that some Scrum adaptations include up to six Artifacts, or documents. However, creating more Artifacts that do not add value or that are otherwise created simply for the sake of creating more Artifacts does not align with the Agile Manifesto value of “more working software, less documentation.”
Scrum Activities (Scrum Events)
The ideas presented in this section align with the typical projects that use the Scrum framework. The Scrum framework organizes work into one‐ to four‐week increments called Sprints. The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to examine and adapt Scrum Artifacts. These activities are specifically designed to enable the transparency required. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Optimally, all events should be held at the same time and place to reduce complexity and increase effectiveness of the team. Each Sprint should bring the product closer to the overall Product Goal and likely will evolve as the Scrum Team learns over time. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective, and Product Backlog refinement/grooming, happen within Sprints. The Product Owner is the only one who can abort the Sprint. There is a specific time frame for each Sprint and a time frame to complete each of the Sprint activities described in the list that follows. The Sprint duration determines the time frame, or “timebox,” for each Sprint activity as noted in the description for each activity. We define and relate each of the five following Scrum Activities to audit activities in Part II:
1 Sprint Planning Meeting (Chapter 9). The Sprint planning meeting is a timeboxed activity (two hours or less per week of Sprint length) held at the beginning of the Sprint to determine the features to be delivered in each Sprint. It is facilitated by the Scrum Master. The Product Owner is an active participant who provides clarity on the upcoming project and related customer stories. The team members collaborate to determine the Sprint tasks, a Definition of Done, and a Definition of Ready. For a two‐week Sprint, the Sprint planning meeting would occur over a four‐hour timebox. For a four‐week Sprint, the Sprint planning meeting would occur over an eight‐hour timebox.
2 Daily Meeting (Chapter 11). The daily meeting may also be called a Daily Sprint, Daily Scrum, or daily standup. For a two‐week Sprint, the daily meeting lasts no more than 15 minutes; for a four‐week Sprint, the daily meeting lasts no more than 30 minutes. The Scrum Master facilitates the meeting, which is held virtually or in a public location at the same time and place each day. Team members take part, provide updates, and give feedback during the meeting. The meeting helps increase transparency on the Sprint and increases communication among the team members. While only the development team provides updates, others may observe the meeting. The Scrum Master ensures meeting productivity and limits unnecessary contributions, updates, and questions.
3 Sprint Review (Chapter 11). The Sprint Review is the Scrum Delivery Team's presentation of their increment, or product, that will be provided to the customer. The development team also provides a summary of the increment and any incomplete tasks. The Product Owner has the authority to approve the increment during the Sprint Review. This review meeting occurs at the end of a Sprint. The Sprint
