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 Review is timeboxed to one hour or less for every week of Sprint length. For a two‐week Sprint, the Sprint Review is limited to two hours.
4 Sprint Retrospective (Chapter 11). The Sprint Retrospective is a “lessons learned” and continuous improvement meeting that lasts one‐hour for a two‐week Sprint. Team members, Scrum Masters, and the Product Owner discuss what worked well and what can be improved on the next Sprint. This one‐hour meeting is held immediately following the Sprint Review.
5 Product Backlog Refinement/Grooming (Chapter 8). The Product Backlog refinement meeting is led by the Product Owner, who engages the team members, Scrum Master, stakeholders, and others to determine the next highest priority item(s) on the Product Backlog for the next Sprint. Typically, this two‐hour meeting occurs the morning after a Sprint Retrospective.
Nevertheless, while the durations provided in this list represent typical projects that use the Scrum framework, our Agile audit framework does not subscribe to doubling the time frame in the timeboxed activities unless there is a legitimate and valuable reason to do so. Additionally, we consistently use a two‐week Sprint.
Figure 1.2 visually depicts how the Scrum roles, Artifacts, and activities fit together. In Chapter 4, What Is Agile Audit?, we alter this diagram for the Agile auditing framework.
There is plenty of evidence supporting Agile in any form. According to an article by Consultancy.eu (a European online platform for the advisory and consulting industry), a study by Organize Agile among professionals in 19 countries reported that 83% of respondents said “it is the ability to improve flexibility amid a rapidly changing environment” that makes Agile appealing. “Leveraging a quicker way of bringing incremental innovations and new products/services to the market, companies can timely cater to the changing needs of customers and try to stay ahead of their competition. Sticking to the traditional Waterfall approach in today's environment often means that organizations are left a step behind of their competition” (Consultancy.eu 2020). Auditing must adopt Agile practices to keep up with business needs and avoid being outsourced, or worse, eliminated tomorrow.
Even the Project Management Institute's flagship publication and fundamental resource for effective project management in any industry, the PMBOK (currently in its sixth edition), has been updated to include information on Agile practices alongside traditional approaches with its guidance. It states, “So why an Agile Practice Guide and why now? Project teams have used Agile techniques and approaches in various forms for at least several decades. The Agile Manifesto expressed definitive values and principles of Agile as the use of Agile gained substantial momentum. Today, project leaders and teams find themselves in an environment disrupted by exponential advances in technology and demands from customers for more immediate delivery of value. Agile techniques and approaches effectively manage disruptive technologies.