Scrum is a framework for project management with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members who break their work into goals that can be completed within time-boxed iterations, called sprints, no longer than one month and most commonly two weeks. The scrum team assesses progress in time-boxed daily meetings of 15 minutes or fewer, called daily scrums (a form of stand-up meeting). At the end of the sprint, the team holds two further meetings: one sprint review intended to demonstrate the work done for stakeholders and elicit feedback, and one sprint retrospective intended to enable the team to reflect and improve.

The term scrum is borrowed from rugby, where it is a formation of players. The term scrum was chosen by the paper's authors because it implies teamwork.[4] The software development term scrum was first used in a 1986 paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka.[5][6] The paper was published in the Jan 1986 issue of Harvard Business Review.

Scrum is occasionally seen written in all-capitals, as SCRUM.[7] While the word itself is not an acronym, its capitalized styling likely comes from an early paper by Ken Schwaber[8] that capitalized SCRUM in its title.[9][10]

While the trademark on the term scrum itself has been allowed to lapse, it is now deemed as a generic trademark owned by the wider community rather than an individual.[11]

Key ideas

Scrum is a lightweight, iterative, and incremental framework for developing, delivering, and sustaining complex products.[12][13] The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility[14]) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. These changes come from a variety of sources, but according to scrum, understanding why is irrelevant, and change should simply be accepted, embraced, and analyzed for benefits.

History

Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, 'The New New Product Development Game'.[15] Takeuchi and Nonaka later argued in The Knowledge Creating Company[16] that it is a form of "organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally".

The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier, and printer industries.[15] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth".[15] (In rugby football, a scrum is used to restart play, as the forwards of each team interlock with their heads down and attempt to gain possession of the ball.[17])

The scrum framework was based on research by Schwaber with Babatunde Ogunnaike at DuPont Research Station and University of Delaware.[9] Ogunnaike advised that attempts to develop complex products, such as software, that weren't based in empiricism were doomed to higher risks and rates of failure as the initial conditions and assumptions change. Empiricism, using frequent inspection and adaptation, with flexibility and transparency is the most suitable approach.

In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.[18]

Sutherland and Schwaber worked together to integrate their ideas into a single framework, scrum. They tested scrum and continually improved it, leading to their 1995 paper,[19] contributions to the Manifesto for Agile Software Development in 2001,[20] and the worldwide spread and use of scrum since 2002.

In 1995, Sutherland and Schwaber jointly presented a paper describing the scrum framework at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas.[19] Over the following years, Schwaber and Sutherland collaborated to combine this material—with their experience and evolving good practice—to develop what became known as scrum.[3]

In 2001, Schwaber worked with Mike Beedle to describe the method in the book, Agile Software Development with Scrum.[21] Scrum's approach to planning and managing product development involves bringing decision-making authority to the level of operation properties and certainties.[9]

In 2002, Schwaber with others founded the Scrum Alliance[22] and set up the Certified Scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org[23] which oversees the parallel Professional Scrum accreditation series.[24]

Scrum Team

The fundamental unit of scrum is a small team of people, consisting of a product owner, a scrum master, and developers. The team is self-managing, cross-functional and focuses on one objective at a time: the product goal.

Product owner

The product owner, representing the product's stakeholders and the voice of the customer (or may represent the desires of a committee[25]), is responsible for delivering good business results.[26] Hence, the product owner is accountable for the product backlog and for maximizing the value that the team delivers.[25] The product owner defines the product in terms of customer-centric outcomes (typically - but not limited to - user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies.[27] A scrum team should have only one product owner (although a product owner could support more than one team)[28] and it is strongly advised against combining this role with the role of the scrum master. The product owner should focus on the business side of product development and spend the majority of time liaising with stakeholders and the team. The product owner does not dictate how the team reaches a technical solution, but seeks consensus among team members.[29][30][31][better source needed] This role is crucial and requires a deep understanding of both sides: the business and the engineers (developers) in the scrum team. Therefore, a good product owner should be able to communicate what the business needs, ask why they need it (because there may be better ways to achieve that), and convey the message to all stakeholders including the developers using technical language, as required. The product owner uses scrum's empirical tools to manage highly complex work while controlling risk and achieving value.

Communication is a core responsibility of the product owner. The ability to convey priorities and empathize with team members and stakeholders is vital to steer product development in the right direction. The product owner role bridges the communication gap between the team and its stakeholders, serving as a proxy for stakeholders to the team and as a team representative to the overall stakeholder community.[32][33]

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the stakeholders:[34]

• Define and announce releases.
• Communicate delivery and product status.
• Share progress during governance meetings.
• Share significant RIDAs (risks, impediments, dependencies, and assumptions) with stakeholders.
• Negotiate priorities, scope, funding, and schedule.
• Ensure that the product backlog is visible, transparent and clear.
• Ability to relate is a key attribute for a product owner to have—the ability to put one's self in another's shoes. A product owner converses with different stakeholders with a variety of backgrounds, job roles, and objectives - and should be able to appreciate these different points of view. To be effective, it is wise for a product owner to know the level of detail the audience needs. The developers need thorough feedback and specifications so they can build a product up to expectation, while an executive sponsor may just need summaries of progress. Providing more information than necessary may lose stakeholder interest and waste time. A direct means of communication is preferred by seasoned product owners.[28]

A product owner's ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.

Developers

The developers carry out all work required to build increments of value every sprint.[27]

The term developers[3] refers to anyone who plays a role in the development and support of the system or product, and can include researchers, architects, designers, data specialists, statisticians, analysts, engineers, programmers, and testers, among others.[35] However, due to the confusion that can arise when some people do not feel the term 'developer' applies to them, they are often referred to just as team members.

The team is self-organizing. While no work should come to the team except through the product owner, and the scrum master is expected to protect the team from distractions, the team are encouraged to interact directly with customers and/or stakeholders to gain maximum understanding and immediacy of feedback.[27]

Scrum master

Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.[36] The scrum master is not a traditional team lead or project manager but acts as a barrier between the team and any distracting influences. The scrum master ensures that the scrum framework is followed by coaching the team in scrum theory and concepts, often facilitating key sessions, and encourages the team to grow and to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

The core responsibilities of a scrum master include (but are not limited to):[37]

• Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
• Helping the team to determine the definition of done for the product, with input from key stakeholders
• Coaching the team, within the scrum principles, in order to deliver high-quality features for its product[38]
• Educating key stakeholders and the rest of the organization on scrum (and possibly agile) principles
• Helping the scrum team avoid or remove impediments to its progress, whether internal or external to the team
• Promoting self-organization and cross-functionality within the team
• Facilitating team events to ensure regular progress
• The scrum master helps people and organizations adopt empirical and lean thinking, leaving behind hopes for certainty and predictability.

One of the ways the scrum master role differs from a project manager is that the latter may have people management responsibilities and the scrum master does not. A scrum master provides a limited amount of direction since the team is expected to be empowered and self-organizing.[39] Scrum does not formally recognize the role of project manager, as traditional command and control tendencies would cause difficulties.[40]

Workflow

Sprint

A sprint (also known as an iteration, timebox or design sprint) is the basic unit of development in scrum. The sprint is a timeboxed effort; that is, the length is agreed and fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.[9]

Usually, daily meetings are held to discuss the progress of the project undertaken and any difficulty faced by any team member of the team while implementing the project. The outcome of the sprint is a deliverable, albeit with some increments. The scrum is used for projects like Web Technology or development of a product for the new market, i.e. the product with many requirements or fast-changing requirement.

Each sprint starts with a sprint planning event in which a sprint goal is defined. Priorities for the upcoming sprint are chosen out of the backlog. Each sprint ends with two events:

• a sprint review (progress shown to stakeholders to elicit their feedback)
• a sprint retrospective (identify lessons and improvements for the next sprints).[18]
• Scrum emphasizes valuable, actionable output at the end of the sprint that just was completed. The output of each iteration should bring the developed product closer to market success.[41] In the case of software, this likely includes that products are fully integrated, tested and documented, and potentially releasable.[40]

Sprint planning

At the beginning of a sprint, the scrum team holds a sprint planning event to:

Agree on the sprint goal, a short description of what they forecast to deliver by sprint end, based on the priorities set by the product owner
Select product backlog items that contribute towards this goal
Form a sprint backlog by mutually discussing and agreeing on which items are intended to be done during that sprint
The maximum duration of sprint planning is eight hours for a four-week sprint.[3] As the detailed work is elaborated, some product backlog items may be split or returned to the product backlog if the team believes they cannot complete that work in a single sprint.

Daily scrum

A daily scrum in the computing room. This centralized location helps the team start on time.
Each day during a sprint, the developers hold a daily scrum (sometimes conducted standing up) with specific guidelines:[42][9]

All developers come prepared. The daily scrum:

• is focused on inspecting progress towards the sprint goal
• should happen at the same time and place every day
• is limited (timeboxed) to fifteen minutes
• is conducted however the team decides
• may include others, though only developers should speak.
• may be facilitated by the scrum master
• may identify impediments to progress (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded)[43]
• does not feature discussions
• is not a means of updating progress charts
• No detailed discussions should happen during the daily scrum. Once over, individual members can discuss issues in detail, often known as a 'breakout session' or an 'after party'.[44] Issues or bugs identified should be collectively discussed outside of the daily scrum with a view to working toward a resolution.

Where the team does not see the value in this event, it is the responsibility of the scrum master to determine why[45] and educate the team and stakeholders about scrum principles,[38] or encourage the team to design their own method of keeping the team fully informed of sprint progress.

Sprint review

Conducted at the end of a sprint, the team:

• presents the completed work to the stakeholders (a.k.a. the demo)
• collaborates with stakeholders on topics such as:
• inviting feedback about the completed product increment
• discussing the impact of incomplete work (planned or otherwise)
• receiving suggestions for upcoming work (guidance of what to work on next)
• Product Owners should see this event as a valuable opportunity to review and refine the product backlog with stakeholders. If review implies any deviations in the product, then adjustments are made as soon as possible to control further deviation.

Guidelines for sprint reviews:

• Incomplete work should not be demonstrated; although stakeholders should be presented with product increments they will be receiving, but can also request to see work in progress if necessary. However, the team should only be prepared to show what has been done.
• The recommended duration is two hours for a two-week sprint (proportional for other sprint-durations).[3]
• Sprint retrospective

At the sprint retrospective, the team:

• reflects on the past sprint(s)
• inspects how the last Sprint went (individuals, interactions, processes, tools, Definition of Done)
• identifies and agrees on continuous process improvement actions
• Guidelines for sprint retrospectives:[citation needed]

Three suggested areas to consider in sprint retrospectives are:

• What went well during the sprint?
• What did not go well?
• What could we do differently the next sprint?
• The duration is maximum of three hours for a four-week sprint, proportional for other sprint duration(s)(e.g. one-and-a-half hours for a two-week sprint).
• The scrum master may facilitate this event, but they can also be present just as a part of the team.

Backlog refinement

Although not originally a core scrum practice, backlog refinement (formerly called grooming) was added to the Scrum Guide and adopted as a way of managing the quality of product backlog items entering a sprint. It is the ongoing process of reviewing and amending/updating/re-ordering product backlog items in the light of new information.

Reasons for modifying the backlog and items within may include:

• Larger items may be broken into multiple smaller ones
• Acceptance criteria may be clarified
• Dependencies may be identified and investigated
• An item may require further discovery and analysis
• Priorities may have changed; expected returns will now differ
• Refinement means that items are appropriately prepared and ordered in a way that makes them clear and executable for developers for sprint planning.

The backlog can also include technical debt (also known as design debt or code debt). This is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

It is recommended to invest of up to 10 percent of a team's sprint capacity[3] upon backlog refinement. More mature teams will not see this as a scheduled defined event but as an ad-hoc activity that forms part of the natural workflow, refining and adjusting the product backlog when needed.

Canceling a sprint

The product owner can cancel a sprint if necessary,[3] and may do so with input from others (developers, scrum master or management). For example, recent external circumstances may negate the value of the sprint goal, so it is pointless in continuing.

When a sprint is abnormally terminated, the next step is to conduct new sprint planning, where the reason for the termination is reviewed.

Terminologies

Sprint works in conjunction with Sprint Backlog, Daily Scrum, Sprint Review and other such events.[54]

Product Owner

Product Owner is responsible for product's current state of development and for maximizing the product's value. Product Owner can be one person, even if they represent a committee.[54] Their job includes:

Maintaining items in Product Backlog.

• Assigning order to items in Backlog.
• Ensuring that items in Product Backlog are clear to the Development Team.[54]
• Development Team
• The development team is responsible for the implementation of the articles in Sprint Backlog. Although several members of the development team may specialize in different areas, the development team as a whole is responsible for the development of functionality.[54]

Sprint Backlog

Sprint Backlog refers to a subset of Product Backlog that is selected for a Sprint along with its delivery plan. Based on the items in the Sprint Backlog, the Development Team decides how they will create a "Done" product.[54]

Daily Scrum

Daily Scrum is a fixed time, fixed place event that allows Development Team to synchronize and plan work for the next 24 hours based on the amount of work done since the last Daily Scrum.[54] During Daily Scrum, Development Team members explain:

• What did I do yesterday that helped towards Sprint Goal?
• What am I going to do today towards my Sprint Goal?
• What Impediments I see towards accomplishing my Sprint Goal?
• Daily Scrum usually lasts for 15 minutes, but can be followed by other meetings for detailed discussions.

Sprint Review

Sprint Review is scheduled after the sprint ends. The team and stakeholders inspect the amount of work done. The Product Owner adapts the Product Backlog if necessary.[54] Sprint review is one inspect-and-adapt opportunity at the end of each sprint.

Sprint Retrospective

Sprint Retrospective is used to analyze what went right in the Sprint and what could be improved upon. The Scrum Team examines the process used to build that increment. This Retrospective feedback helps improve the process in Sprints to follow. Sprint retrospective is one inspect-and-adapt opportunity at the end of each sprint.[55]

References

Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
"Lessons learned: Using Scrum in non-technical teams". Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
Ken Schwaber; Jeff Sutherland. "The Scrum Guide". Scrum.org. Retrieved October 27, 2017.
"Scrum, What's in a Name? – DZone Agile". dzone.com.
"Archived copy" (PDF). Archived from the original (PDF) on February 9, 2021. Retrieved April 7, 2021.
"The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka (1986)
"Should "SCRUM" be written in all caps?". stackoverflow.com. Retrieved January 10, 2017.
"Scrum.org Ken Schwaber". Retrieved February 13, 2022.
Schwaber, Ken (February 1, 2004). Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-7356-1993-7.
Schwaber, Ken (2004). "SCRUM Development Process" (PDF). Advanced Development Methods.
Johnson, Hillary Louise (January 13, 2011). "ScrumMaster vs scrum master: What do you think?". agilelearninglabs.com. Retrieved May 10, 2017.
"What is Scrum?". What is Scrum? An Agile Framework for Completing Complex Projects – Scrum Alliance. Scrum Alliance. Retrieved February 24, 2016.
Verheyen, Gunther (March 21, 2013). "Scrum: Framework, not methodology". Gunther Verheyen. Gunther Verheyen. Retrieved February 24, 2016.
J. Henry and S. Henry. Quantitative assessment of the software maintenance process and requirements volatility. In Proc. of the ACM Conference on Computer Science, pages 346–351, 1993.
Takeuchi, Hirotaka; Nonaka, Ikujiro (January 1, 1986). "The New New Product Development Game". Harvard Business Review. Retrieved June 9, 2010. Moving the Scrum Downfield
The Knowledge Creating Company. Oxford University Press. 1995. p. 3. ISBN 9780199762330. Retrieved March 12, 2013.
"Scrum". Lexico UK English Dictionary. Oxford University Press. Archived from the original on March 22, 2020.
Sutherland, Jeff (October 2004). "Agile Development: Lessons learned from the first Scrum". Archived from the original (PDF) on June 30, 2014. Retrieved September 26, 2008.
Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business object design and implementation: OOPSLA '95 workshop proceedings. The University of Michigan. p. 118. ISBN 978-3-540-76096-2.
"Manifesto for Agile Software Development". Retrieved October 17, 2019.
Schwaber, Ken; Beedle, Mike (2002). Agile software development with Scrum. Prentice Hall. ISBN 978-0-13-067634-4.
Maximini, Dominik (January 8, 2015). The Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals. Cham: Springer (published 2015). p. 26. ISBN 9783319118277. Retrieved August 25, 2016. Ken Schwaber and Jeff Sutherland presented Scrum for the first time at the OOPSLA conference in Austin, Texas, in 1995. […] In 2001, the first book about Scrum was published. […] One year later (2002), Ken founded the Scrum Alliance, aiming at providing worldwide Scrum training and certification.
"Home". Scrum.org. Retrieved January 6, 2020.
Partogi, Joshua (July 7, 2013). "Certified Scrum Master vs Professional Scrum Master". Lean Agile Institute. Retrieved May 10, 2017.
McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley, p. 173, ISBN 978-0-13-704329-3
Morris, David (2017). Scrum: an ideal framework for agile projects. In Easy Steps. pp. 178–179. ISBN 9781840787313. OCLC 951453155.
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, NJ: Addison-Wesley, 2010.
"The Scrum Guide" (PDF).
The Scrum guide (PDF). p. 6.
"The Role of the Product Owner". Scrum Alliance. Retrieved May 26, 2018.
Pichler, Roman (March 11, 2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. ISBN 978-0-321-68413-4.
Ambler, Scott. "The Product Owner Role: A Stakeholder Proxy for Agile Teams". agilemodeling.com. Retrieved July 22, 2016. […] in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
"The Product Owner Role". Scrum Master Test Prep. Retrieved February 3, 2017.
Rad, Nader K.; Turley, Frank (2018). Agile Scrum Foundation Courseware, Second Edition. 's-Hertogenbosch, Netherlands: Van Haren. p. 26. ISBN 9789401802796.
Carroll, N, O’Connor, M. and Edison, H. (2018). The Identification and Classification of Impediments to Software Flow, The Americas Conference on Information Systems (AMCIS 2018), August 16–18, New Orleans, Louisiana, USA.
"Core Scrum". Scrum Alliance. Retrieved January 25, 2015.
Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps. Birmingham, UK: Packt Publishing Ltd. p. 43. ISBN 9781786467041.
Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken, NJ: John Wiley & Sons. p. 37. ISBN 9781118991046.
Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (December 17, 2012). "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)". InfoQ.
Marta Dunajko (March 3, 2022). "Planning in Scrum – how to make it effective?". Neurosys.com. Retrieved August 4, 2022.
"What is a Daily Scrum?". Scrum.org. Retrieved January 6, 2020.
Little, Joe (January 17, 2011). "Impediment Management". Agile Consortium.
Flewelling, Paul (2018). The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology. Birmingham, UK: Packt Publishing Ltd. p. 91. ISBN 9781787280205.
McKenna, Dave (2016). The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility. Aliquippa, PA: CA Press. p. 126. ISBN 9781484222768.
Higgins, Tony (March 31, 2009). "Authoring Requirements in an Agile World". BA Times.
"The product backlog: your ultimate to-do list". Atlassian. Retrieved July 20, 2016.
Pichler, Roman. Agile Product Management with Scrum: Creating Products that Customers Love. Upper Saddle River, NJ: Addison-Wesley, 2010.[need quotation to verify]
Russ J. Martinelli; Dragan Z. Milosevic (January 5, 2016). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. p. 304. ISBN 978-1-118-97320-2.
Charles G. Cobb (January 27, 2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. John Wiley & Sons. p. 378. ISBN 978-1-118-99104-6.
Ken Schwaber, Agile Project Management with Scrum, p.55
"Create a Spike Solution". Extreme Programming.
Sterling, Chris (October 22, 2007). "Research, Spikes, Tracer Bullets, Oh My!". Getting Agile. Retrieved October 23, 2016.
Ken Schwaber, Jeff Sutherland. "The Scrum Guide" (PDF). Scrum.org. Retrieved May 25, 2018.
Rubin, Kenneth (2012), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley (published 2013), p. 375, ISBN 978-0-13-704329-3