Scrum (software development)

Management framework

[[File:Scrum Agile events. png|thumb|Scrum Agile events, based on The 2020 Scrum Guide

Scrum's approach to product development involves bringing decision making authority to an operational level. Unlike a sequential approach to product development, scrum is an iterative and incremental framework for product development. Scrum allows for continuous feedback and flexibility, requiring teams to self organize by encouraging physical co location or close online collaboration, and mandating frequent communication among all team members. The flexible and semi unplanned approach of scrum is based in part on the notion of requirements volatility, that stakeholders will change their requirements as the project evolves.

The use of the term scrum in software development came from a 1986 Harvard Business Review paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. Based on case studies from manufacturing firms in the automotive, photocopier, and printer industries, the authors outlined a new approach to product development for increased speed and flexibility. They called this the rugby approach, as the process involves a single cross functional team operating across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth". The authors later developed scrum in their book, The Knowledge Creating Company. In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods. Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation, referring to the approach with the term scrum. Sutherland and Schwaber later worked together to integrate their ideas into a single framework, formally known as scrum. Schwaber and Sutherland tested scrum and continually improved it, leading to the publication of a research paper in 1995, and the Manifesto for Agile Software Development in 2001. Schwaber also collaborated with Babatunde Ogunnaike at DuPont Research Station and the University of Delaware to develop Scrum. Ogunnaike believed that software development projects could often fail when initial conditions change, if the product management was not rooted in empirical practice. Schwaber left the Scrum Alliance in late 2009 and subsequently founded Scrum. org which oversees the parallel Professional Scrum accreditation series. Since 2009, a public document called The Scrum Guide has been published and updated by Schwaber and Sutherland. It has been revised 6 times, with the current version being November 2020.

A scrum team is organized into at least three categories of individuals: the product owner, developers, and the scrum master. The product owner liaises with stakeholders, those who have interest in the project's outcome, to communicate tasks and expectations with developers. Developers in a scrum team organize work by themselves, with the facilitation of a scrum master. Scrum teams, ideally, should abide by the five values of scrum: commitment, courage, focus, openness, and respect. The product owner focuses on the business side of product development and spends the majority of time liaising with stakeholders and the team. The role is intended to primarily represent the product's stakeholders, the voice of the customer, or the desires of a committee, and bears responsibility for the delivery of business results. Product owners manage the product backlog, which is essentially the project's running to do list, and are responsible for maximizing the value that a team delivers. As the primary liaison of the scrum team towards stakeholders, product owners are responsible for communicating announcements, project definitions and progress, RIDAs (risks, impediments, dependencies, and assumptions), funding and scheduling changes, the product backlog, and project governance, among other responsibilities. Product owners can also cancel a sprint if necessary, without the input of team members.

Scrum is facilitated by a scrum master, whose role is to educate and coach teams about scrum theory and practice. Scrum masters have differing roles and responsibilities from traditional team leads or project managers. Some scrum master responsibilities include coaching, objective setting, problem solving, oversight, planning, backlog management, and communication facilitation.

Conducted at the end of a sprint, a sprint review is a meeting that has a team share the work they've completed with stakeholders and liaise with them on feedback, expectations, and upcoming plans. At a sprint review completed deliverables are demonstrated to stakeholders, who should also be made aware of product increments and works in progress. The recommended duration for a sprint review is one hours per week of sprint.

Backlog refinement is a process by which team members revise and prioritize a backlog for future sprints. It can be done as a separate stage done before the beginning of a new sprint or as a continuous process that team members work on by themselves. Backlog refinement can include the breaking down of large tasks into smaller and clearer ones, the clarification of success criteria, and the revision of changing priorities and returns. It is recommended to invest of up to 10 percent of a team's sprint capacity on backlog refinement. The product owner maintains and prioritizes product backlog items based on considerations such as risk, business value, dependencies, size, and timing. High priority items at the top of the backlog are broken down into more detail for developers to work on, while tasks further down the backlog may be more vague. Developers fill this backlog with tasks they deem appropriate to fill the sprint, using past performance to assess their capacity for each sprint. The scrum approach has tasks on the sprint backlog not assigned to developers by any particular individual or leader. Team members self organize by pulling work as needed according to the backlog priority and their own capabilities and capacity.

An increment is a potentially releasable output of a sprint, which meets the sprint goal. It is formed from all the completed sprint backlog items, integrated with the work of all previous sprints. An ideal increment is complete, fully functioning, and in a usable condition.

thumb|A sample burndown chart for a completed sprint, showing remaining effort at the end of each day.|385x385px

Often used in scrum, a burndown chart is a publicly displayed chart showing remaining work. Updated every day, it provides quick visualizations for reference. The horizontal axis of the burndown chart shows the days remaining, while the vertical axis shows the amount of work remaining each day. During sprint planning, the ideal burndown chart is plotted. Then, during the sprint, developers update the chart with remaining work so the chart is updated day by day, showing a comparison between actual and predicted.

Some project managers believe that a team's total capability effort for a single sprint can be derived by evaluating work completed in the last sprint. The collection of historical "velocity" data is a guideline for assisting the team in understanding their capacity. Nonetheless, the concept of velocity has been controversial among scrum practitioners.

Some have argued that scrum events, such as daily scrum and scrum review, hurt productivity and waste time that could be better spent on actual productive tasks. In practice, many scrum practitioners conduct events, like the daily scrum, as an extended discussion, without complying with the time boxing requirement. Scrum has also been observed to pose difficulties for a number of types of teams, including those which are part time or geographically distant; which have members that are highly specialized and would be better off working by themselves or in working cliques; which have many external dependencies that disrupt planned short sprints of work from occurring; and which are unsuitable for incremental and development testing.

Scrum is frequently tailored or adapted in different contexts to achieve varying aims. A common approach to adapting scrum is the combination of scrum with other software development methodologies, as scrum does not cover the whole product development lifecycle. Various scrum practitioners have also suggested more detailed techniques for how to apply or adapt scrum to particular problems or organizations. Many refer to these techniques as 'patterns', an analogous use to design patterns in architecture and software.

Scrumban is a software production model based on scrum and kanban. To illustrate each stage of work, teams working in the same space often use post it notes or a large whiteboard. Scrumban is especially suited for product maintenance with frequent and unexpected work items, such as production defects or programming errors. In such cases time limited scrum sprints may not be as beneficial, although scrum's daily events and other practices can still be applied. At the same time, kanban models allow a team to visualize work stages and limitations.

Scrum of scrums is a technique to operate scrum at scale, for multiple teams coordinating on the same product. Scrum of scrums daily scrum meetings involve ambassadors selected from each individual team, who may be either a developer or scrum master. As a tool for coordination, scrum of scrums allows teams to collectively work on team wide risks, impediments, dependencies, and assumptions (RIDAs), which may be tracked in a backlog of its own.

Large scale scrum is a product development framework that scales scrum with varied rules and guidelines, developed by Bas Vodde and Craig Larman. There are two levels to the framework: the first level, designed for up to eight teams; and the second level, known as 'LeSS Huge', which can accommodate development involving hundreds of developers.