Scrum (project management)

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 product management was not rooted in empirical practice. In 2002, Schwaber with others founded the Scrum Alliance and set up the Certified Scrum accreditation series. 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 six times, with the most recent version having been published in November 2020. == Scrum team ==

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 an 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. Product owner Each scrum team has one product owner. 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 and are responsible for maximizing the value that a team delivers. Scrum master 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 team leads or project managers; project managers often have people management responsibilities, which a scrum master does not. Scrum teams do not involve project managers to maximize self-organisation among developers. == Workflow ==

Sprint A sprint (also known as a design sprint, iteration, or timebox) is a fixed period of time wherein team members work on a specific goal. Each sprint is normally between one week and one month, with two weeks being the most common. The goal of the sprint should be to produce something that is tangible and "done", and the goal is treated as immutable to give the team certainty. If the goal needs to be changed due to a change in external priorities, the product owner or the team can terminate the sprint and start a new sprint with a new goal. Each sprint starts with a sprint planning event in which a sprint goal is defined and priorities are chosen out of the backlog. The suggested maximum duration of sprint planning is two hours for each week in the sprint. Each sprint ends with a sprint review, where progress shown to stakeholders to elicit their feedback, and a sprint retrospective where the team identifies lessons and improvements for upcoming sprints. Scrum masters are responsible for ensuring that team members use daily scrums effectively or, if team members are unable to use them, providing alternatives to achieve similar outcomes. Post-sprint events 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. The recommended duration for a sprint review is one hour per week of sprint. This process was formerly known as "grooming". == Artifacts ==

Artifacts are a means by which scrum teams manage product development by documenting work done towards the project. There are many kinds of scrum artifacts, with three of them being the most common: product backlog, sprint backlog, and increment. Product backlog The product backlog is a breakdown of work to be done and contains an ordered list of product requirements (such as features, bug fixes and non-functional requirements) that the team maintains for a product. The order of a product backlog corresponds to the urgency of the task. Common formats for backlog items include user stories and use cases. 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. Developers self organize by pulling work as needed according to the backlog priority and their own capabilities and capacity, alongside other factors like learning opportunity. 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 the remaining work. Burnup chart )|384x384px Updated at the end of each sprint, the release burn-up chart shows progress towards delivering a forecast scope. The horizontal axis of the release burnup chart shows the sprints in a release, while the vertical axis shows the amount of work completed at the end of each sprint. Velocity A team's total capability effort for a single sprint can be estimated 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. Definition of done A team's "definition of done" is a checklist of what needs to be completed for work to be considered "done". The definition of done does not necessarily guarantee that the work is ready to be released, as doing so early on in development may not be feasible, instead it represents how close the team can reasonably get with their existing capabilities. As the team improves, the definition of done should evolve to align with what is needed for work to be released. == Criticism ==

Some have argued that scrum events, such as daily scrums and scrum reviews, hurt productivity and waste time that could be better spent on actual productive tasks. Scrum has also been observed to pose difficulties for part-time or geographically distant teams; those that have highly specialized members who would be better off working by themselves or in working cliques; and those that are unsuitable for incremental and development testing. A systematic review found "that Distributed Scrum has no impact, positive or negative on overall project success" in distributed software development. Martin Fowler, one of the authors of the Manifesto for Agile Software Development, has criticized what he calls "faux-agile" practices that are "disregarding Agile's values and principles", and "the Agile Industrial Complex imposing methods upon people" contrary to the Agile principle of valuing "individuals and interactions over processes and tools" == Adaptations ==

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 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. Kanban models allow a team to visualize work stages and limitations. Scrum of scrums 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 their own. Large-scale scrum Large-scale scrum is an organizational system for product development 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. == See also ==