{{Short description|Management framework}} {{About|software development framework||Scrum (disambiguation){{!}}Scrum}} {{Use American English|date=July 2023}} {{Use mdy dates|date=February 2022}} {{Software development process}} [[File:Scrum Agile events.png|thumb|Scrum Agile events, based on ''The 2020 Scrum Guide''<ref name ="scrumguidepdf2020">{{cite web |author=Ken Schwaber |author2=Jeff Sutherland |title=The Scrum Guide |url=https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf |access-date=June 15, 2023 |publisher=Scrum.org}}</ref>]]
'''Scrum''' is an agile team collaboration framework commonly used in software development and other industries.
Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called ''sprints''. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called ''daily scrums''. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. A person in charge of a scrum team is typically called a ''scrum master''.<ref>{{Cite web |title=What Is A Scrum Master? Everything You Need To Know – Forbes Advisor |url=https://www.forbes.com/advisor/business/what-is-a-scrum-master/ |access-date=2023-11-16 |website=www.forbes.com|date=December 27, 2021 }}</ref>
Scrum teams should be cross-functional and self-managing. Unlike sequential approaches, scrum is an iterative and incremental framework for product development.<ref name="scrumprimer" /> 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 approach of scrum is based in part on the notion of requirement volatility, that stakeholders will change their requirements as the project evolves.<ref>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.</ref>
{{TOC limit|3}}
== History == 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".<ref name="TakeuchiNonaka">{{Cite journal |last1=Takeuchi |first1=Hirotaka |last2=Nonaka |first2=Ikujiro |date=January 1, 1986 |title=The New New Product Development Game |url=https://cb.hbsp.harvard.edu/cbmp/product/86116-PDF-ENG |journal=Harvard Business Review |access-date=June 9, 2010 |quote=Moving the Scrum Downfield}}</ref> The authors later developed scrum in their book, ''The Knowledge Creating Company''.<ref>{{Cite book |url=https://books.google.com/books?id=B-qxrPaU1-MC&q=The+Knowledge+Creating+Company |title=The Knowledge Creating Company |publisher=Oxford University Press |year=1995 |isbn=978-0-19-976233-0 |page=3 |access-date=March 12, 2013}}</ref>
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''.<ref name="autogenerated1">{{cite web |title=Agile Development: Lessons learned from the first Scrum |url=https://www.scrumalliance.org/resource_download/35 |last=Sutherland |first=Jeff |author-link=Jeff Sutherland |date=October 2004 |format=PDF |archive-url=https://web.archive.org/web/20140630020607/http://www.scrumalliance.org/resource_download/35 |archive-date=June 30, 2014 |access-date=September 26, 2008}}</ref> 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,<ref name="OOPSLA95">{{Cite book |last1=Sutherland |first1=Jeffrey Victor |title=Business object design and implementation: OOPSLA '95 workshop proceedings |last2=Schwaber |first2=Ken |publisher=The University of Michigan |year=1995 |isbn=978-3-540-76096-2 |page=118 |author-link=Jeff Sutherland |author-link2=Ken Schwaber}}</ref> and the Manifesto for Agile Software Development in 2001.<ref name="agilemanifesto">{{cite web |title=Manifesto for Agile Software Development |url=https://agilemanifesto.org |access-date=October 17, 2019}}</ref> 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.<ref name="schwaber">{{Cite book |last=Schwaber |first=Ken |url=https://archive.org/details/agileprojectmana0000schw |title=Agile Project Management with Scrum |date=February 1, 2004 |publisher=Microsoft Press |isbn=978-0-7356-1993-7 |author-link=Ken Schwaber |url-access=registration}}</ref>
In 2002, Schwaber with others founded the Scrum Alliance and set up the ''Certified Scrum'' accreditation series.<ref>{{Cite book |last=Maximini |first=Dominik |url=https://books.google.com/books?id=ShojBgAAQBAJ |title=The Scrum Culture: Introducing Agile Methods in Organizations |date=January 8, 2015 |publisher=Springer |isbn=978-3-319-11827-7 |series=Management for Professionals |location=Cham |publication-date=2015 |page=26 |quote=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. |access-date=August 25, 2016}}</ref> Schwaber left the Scrum Alliance in late 2009 and subsequently founded Scrum.org, which oversees the parallel ''Professional Scrum'' accreditation series.<ref>{{cite web |title=Home |url=https://www.scrum.org/index |access-date=January 6, 2020 |website=Scrum.org |language=en}}</ref> Since 2009, a public document called ''The Scrum Guide''<ref name="scrumguidesite">{{cite web |last1=Sutherland |first1=Jeff |author1-link=Jeff Sutherland |last2=Schwaber |first2=Ken |author2-link=Ken Schwaber |year=2013 |title=Scrum Guides |url=http://www.scrumguides.org/ |access-date=June 15, 2023 |publisher=ScrumGuides.org}}</ref> 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.<ref name=":0">{{Cite book |last=Morris |first=David |title=Scrum: an ideal framework for agile projects |publisher=In Easy Steps |year=2017 |isbn=978-1-84078-731-3 |pages=178–179 |oclc=951453155}}</ref> Developers in a scrum team organize work by themselves, with the facilitation of a scrum master.<ref>{{Cite book |last=Cobb |first=Charles G. |title=The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach |date=2015 |publisher=John Wiley & Sons |isbn=978-1-118-99104-6 |location=Hoboken, NJ |page=37}}</ref>
=== Product owner === Each scrum team has one product owner.<ref name=":1">{{Cite book |last=Cohn |first=Mike |title=Succeeding with Agile: Software Development Using Scrum |date=2010 |publisher=Addison-Wesley |isbn=978-0-321-57936-2 |location=Upper Saddle River, NJ |author-link=Mike Cohn}}</ref> 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.<ref name="Essential Scrum: Velocity">{{Citation |last=Rubin |first=Kenneth |title=Essential Scrum. A Practical Guide to the Most Popular Agile Process |pages=173,375 |date=2013 |publisher=Addison-Wesley |language=EN |isbn=978-0-13-704329-3}}</ref><ref name=":3">{{Cite book |last1=McGreal |first1=Don |url=https://books.google.com/books?id=cEBbDwAAQBAJ&q=scrum+product+owner+accountable+backlog&pg=PT173 |title=The Professional Product Owner: Leveraging Scrum as a Competitive Advantage |last2=Jocham |first2=Ralph |date=June 4, 2018 |publisher=Addison-Wesley Professional |isbn=978-0-13-468665-3 |language=en}}</ref><ref>{{Cite book |last=Pichler |first=Roman |title=Agile Product Management with Scrum: Creating Products that Customers Love |date=March 11, 2010 |publisher=Addison-Wesley Professional |isbn=978-0-321-68413-4 |language=en}}</ref> Product owners manage the product backlog and are responsible for maximizing the value that a team delivers.<ref name=":3" /> However, it is the developers, not the product owner, who decide how much to do in each sprint and how to accomplish it.<ref name="scrumprimer" />
=== Developers === In scrum, the term ''developer'' or ''team member'' refers to anyone who plays a role in the development and support of the product and can include researchers, architects, designers, programmers, etc.<ref name="scrumguidesite" /><ref name=":2">{{Cite book |last1=Rad |first1=Nader K. |title=Agile Scrum Foundation Courseware, Second Edition |last2=Turley |first2=Frank |date=2018 |publisher=Van Haren |isbn=978-94-018-0279-6 |location='s-Hertogenbosch, Netherlands |page=26}}</ref>
=== 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.<ref name="scrumprimer">{{cite web |title=The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0) |url=http://www.infoq.com/minibooks/Scrum_Primer |last1=Pete Deemer |last2=Gabrielle Benefield |date=December 17, 2012 |publisher=InfoQ |last3=Craig Larman |last4=Bas Vodde}}</ref>
== Workflow == === Sprint === {{Distinguish|Hackathon#Code sprints}} thumb|right|The scrum framework (PBI in the figure refers to product backlog item) thumb|The scrum process 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.<ref name="scrumprimer" />
===Daily scrum=== {{Main|Daily scrum meeting}}
thumb|A daily scrum in the computing room Each day during a sprint, the developers hold a daily scrum (often conducted standing up) with specific guidelines, which may be facilitated by a scrum master.<ref name="scrumprimer" /> Daily scrum meetings are intended to be less than 15 minutes in length, taking place at the same time and location daily. The purpose of the meeting is to announce progress made towards the sprint goal and issues that may be hindering the goal, without going into any detailed discussion. Once over, individual members can go into a 'breakout session' or an 'after party' for extended discussion and collaboration.<ref name=":5">{{Cite book|last=Flewelling|first=Paul|title=The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology|date=2018|publisher=Packt Publishing Ltd|isbn=978-1-78728-020-5|location=Birmingham, UK|page=91}}</ref> 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.<ref>{{Cite book |last=McKenna |first=Dave |title=The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility |date=2016 |publisher=CA Press |isbn=978-1-4842-2276-8 |location=Aliquippa, PA |page=126 |language=en}}</ref><ref name=":4">{{Cite book|last1=Drongelen|first1=Mike van|title=Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps|last2=Dennis|first2=Adam|last3=Garabedian|first3=Richard|last4=Gonzalez|first4=Alberto|last5=Krishnaswamy|first5=Aravind|date=2017|publisher=Packt Publishing Ltd|isbn=978-1-78646-704-1|location=Birmingham, UK|page=43}}</ref>
===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.<ref name="scrumprimer" />
A sprint retrospective is a separate meeting that allows team members to internally analyze the strengths and weaknesses of the sprint, future areas of improvement, and continuous process improvement actions.<ref name="Essential Scrum: Velocity" />
=== Backlog Refinement === 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.<ref>{{cite web |author=Ken Schwaber and Jeff Sutherland |date=2020-11-18 |title=The Scrum Guide |url=https://scrumguides.org/scrum-guide.html |website=scrumguides.org |language=en |publisher=scrumguides.org|access-date=2025-01-10 |quote=Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. }}</ref> This process was formerly known as "grooming".<ref>{{cite web |author=Ken Schwaber and Jeff Sutherland |date=2020-11-18 |title=Official Scrum Guide Revisions|url=https://scrumguides.org/revisions.html |website=scrumguides.org |language=en |publisher=scrumguides.org|access-date=2025-01-10 |quote=The Product Backlog is refined rather than groomed.}}</ref><ref>{{cite web |author=Project Management Institute (PMI) and Agile Alliance |date=|title=What is Backlog Refinement?|url=https://agilealliance.org/glossary/backlog-refinement/ |website=agilealliance.org |language=en |publisher=agilealliance.org |access-date=2025-01-10 |quote=Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team, review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. }}</ref><ref>{{cite web |author=Atlassian Corporation |date= |title=What is Backlog Refinement?|url=https://www.atlassian.com/agile/scrum/backlog-refinement |website=atlassian.com |language=en |publisher=Atlassian |access-date=2025-01-10 |quote=Although you may still hear “backlog grooming” used, agile backlog refinement seems to be the industry standard, as it better reflects the collaborative and continuous nature of the process.}}</ref>
== 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.{{cn|date=December 2025}}
=== Product backlog === {{main|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.<ref name="scrumprimer" /> The product backlog may also contain the product owner's assessment of business value and the team's assessment of the product's effort or complexity, which can be stated in story points using the rounded Fibonacci scale. These estimates try to help the product owner gauge the timeline and may influence the ordering of product backlog items.<ref>{{cite web |last=Higgins |first=Tony |date=March 31, 2009 |title=Authoring Requirements in an Agile World |url=http://www.batimes.com/articles/authoring-requirements-in-an-agile-world.html |publisher=BA Times}}</ref> 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.<ref name="scrumprimer" />
===Sprint backlog=== The sprint backlog is the subset of items from the product backlog intended for developers to address in a particular sprint.<ref name="MartinelliMilosevic2016">{{Cite book |last1=Russ J. Martinelli |url=https://books.google.com/books?id=SbA7CwAAQBAJ&pg=PA304 |title=Project Management ToolBox: Tools and Techniques for the Practicing Project Manager |last2=Dragan Z. Milosevic |date=January 5, 2016 |publisher=Wiley |isbn=978-1-118-97320-2 |page=304}}</ref> 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.<ref name="scrumprimer" />
=== Increment === An increment is a potentially releasable output of a sprint, which meets the sprint goal and the definition of done. It is formed from all the completed sprint backlog items, integrated with the work of all previous sprints.<ref name="scrumprimer" />
=== Other artifacts === ==== Burndown chart ==== thumb|A sample burndown chart for a completed sprint, showing remaining effort at the end of each day|385x385px {{Main|Burndown chart}}
Often used in scrum, a burndown chart is a publicly displayed chart showing remaining work.<ref name="Cobb2015">{{Cite book |last=Charles G. Cobb |url=https://books.google.com/books?id=vHjTBQAAQBAJ&pg=PA378 |title=The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach |date=January 27, 2015 |publisher=John Wiley & Sons |isbn=978-1-118-99104-6 |page=378}}</ref> 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.<ref>{{cite web |title=Agile 101 – Sprint Planning |url=https://www.somar.co.nz/blog/agile-101-sprint-planning/ |website=Somar Digital |access-date=2025-07-09}}</ref> Then, during the sprint, developers update the chart with the remaining work.
==== Burnup chart ==== [[File:SampleBurnupChart.png|thumb|A sample burnup chart for a release, showing scope completed each sprint (MVP = minimum viable product)|384x384px]] {{main|Burnup chart}} 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.<ref>{{Cite journal |last=Arafeen |first=Junaid |last2=Bose |first2=Saugata |date=September 2009 |title=Improving Software Development Using Scrum Model by Analyzing Up and Down Movements on The Sprint Burn Down Chart: Proposition for Better Alternatives |url=https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=caba1a295763f86fecf970df998c3b6b7be6a0da |journal=International Journal of Digital Content Technology and its Applications |volume=3 |issue=3 |via=CiteSeerX}}</ref>
==== Velocity ==== {{main|Velocity (software development)}} 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.{{cn|date=December 2025}}
==== <span class="anchor" id="Definition of Done (DoD)"></span> Definition of done ==== A team's "definition of done" is a checklist of what needs to be completed for work to be considered "done".{{cn|date=December 2025}} 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.<ref name="scrumprimer" />
{{anchor|Definition of ready}} {{anchor|Definition of ready (DoR)}} A related term is the "definition of ready", which is a checklist of what needs to be completed before starting work on an item.<ref name="pmi-dor">{{cite web |title=Definition of Ready and Different Ways to Use It |url=https://www.pmi.org/disciplined-agile/definition-of-ready-and-different-ways-to-use-it |publisher=Project Management Institute |access-date=22 December 2025}}</ref>
== 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.<ref>{{Cite magazine |date=December 4, 2019 |title=Not all developers like agile, and here are 5 reasons why |url=https://www.bmmagazine.co.uk/in-business/not-all-developers-like-agile-and-here-are-5-reasons-why/ |magazine=Business Matters |access-date=June 5, 2020}}</ref> 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.<ref>{{Cite journal |last1=Turk |first1=Dan |last2=France |first2=Robert |last3=Rumpe |first3=Bernhard |year=2014 |orig-date=2002 |title=Limitations of Agile Software Processes |journal=Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering |pages=43–46 |arxiv=1409.6600}}</ref><ref>{{Cite journal |date=August 2012 |title=Issues and Challenges in Scrum Implementation |url=http://www.ijser.org/researchpaper/Issues-and-Challenges-in-Scrum-Implementation.pdf |journal=International Journal of Scientific & Engineering Research |volume=3 |issue=8 |access-date=December 10, 2015}}</ref>
A systematic review found "that Distributed Scrum has no impact, positive or negative on overall project success" in distributed software development.<ref>{{cite journal |last1=Santos |first1=Ronnie de Souza |last2=Ralph |first2=Paul |last3=Arshad |first3=Arham |last4=Stol |first4=Klaas-Jan |title=Distributed Scrum: A Case Meta-Analysis |journal=ACM Computing Surveys |date=5 October 2023 |volume=56 |issue=4 |pages=1–37 |doi=10.1145/3626519|s2cid=263672588 |doi-access=free }}</ref>
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",<ref name="stateofagile">{{cite web |last1=Fowler |first1=Martin |author1-link=Martin Fowler (software engineer) |title=The State of Agile Software in 2018 |url=https://martinfowler.com/articles/agile-aus-2018.html |website=martinfowler.com |access-date=14 September 2023 |archive-url=https://web.archive.org/web/20230914005209/https://martinfowler.com/articles/agile-aus-2018.html |archive-date=14 September 2023 |date=25 August 2018 |url-status=live}}</ref> and "the Agile Industrial Complex imposing methods upon people" contrary to the Agile principle of valuing "individuals and interactions over processes and tools"<ref name="agilemanifesto" /> and allowing the individuals doing the work to decide how the work is done, changing processes to suit their needs.
In September 2016, Ron Jeffries, a signatory to the Agile Manifesto,<ref name="agilemanifesto" /> described what he called "Dark Scrum", saying that "abuses are almost inevitable until people really learn Scrum’s principles and values". He was particularly focused on the slow uptake of self-organisation.<ref>{{cite web |last1=Jeffries |first1=Ron |title=Dark Scrum |url=https://ronjeffries.com/articles/016-09ff/defense/ |website=ronjeffries.com |access-date=6 May 2024 |date=8 September 2016}}</ref>
== Adaptations == Scrum is frequently tailored or adapted in different contexts to achieve varying aims.<ref>{{Cite journal|last1=Hron|first1=Michal|last2=Obwegeser|first2=Nikolaus|date=January 1, 2022|title=Why and how is Scrum being adapted in practice: A systematic review|url=https://www.sciencedirect.com/science/article/pii/S0164121221002077|journal=Journal of Systems and Software|language=en|volume=183|article-number=111110|doi=10.1016/j.jss.2021.111110|s2cid=240950847 |issn=0164-1212|url-access=subscription}}</ref> 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.<ref>{{Cite journal |last1=Hron, M. |last2=Obwegeser, N. |date=January 2018 |title=Scrum in practice: an overview of Scrum adaptations |url=https://scispace.com/pdf/scrum-in-practice-an-overview-of-scrum-adaptations-3rubqoh47r.pdf |journal=Proceedings of the 2018 51st Hawaii International Conference on System Sciences (HICSS), January 3–6, 2018 }}</ref> 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.<ref>{{cite web |title=Scrum as Organizational Patterns |url=https://sites.google.com/a/scrumorgpatterns.com/www/ |last1=Bjørnvig |first1=Gertrud |last2=Coplien |first2=Jim |date=June 21, 2008 |publisher=Gertrude & Cope |archive-url=https://web.archive.org/web/20121106111033/https://sites.google.com/a/scrumorgpatterns.com/www/ |archive-date=November 6, 2012}}</ref><ref>{{cite web |title=Scrum Pattern Community |url=http://www.scrumplop.org |website=ScrumPLoP.org |access-date=July 22, 2016}}</ref>
=== Scrumban === {{Main|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.<ref name="scrumban">{{cite web |last=Ladas |first=Corey |date=October 27, 2007 |title=scrum-ban |url=http://leansoftwareengineering.com/ksse/scrum-ban/ |archive-url=https://web.archive.org/web/20180823232934/http://leansoftwareengineering.com/ksse/scrum-ban/ |archive-date=August 23, 2018 |access-date=September 13, 2012 |publisher=Lean Software Engineering}}</ref> Kanban models allow a team to visualize work stages and limitations.<ref name="knibergskarin">{{cite web |title=Kanban and Scrum – Making the most of both |url=https://www.infoq.com/minibooks/kanban-scrum-minibook |last1=Kniberg |first1=Henrik |last2=Skarin |first2=Mattias |date=December 21, 2009 |publisher=InfoQ |format=PDF |access-date=July 22, 2016}}</ref>
=== 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.<ref name="scrumofscrums">{{cite web |date=December 17, 2015 |title=Scrum of Scrums |url=http://guide.agilealliance.org/guide/scrumofscrums.html |archive-url=https://web.archive.org/web/20140209200853/http://guide.agilealliance.org/guide/scrumofscrums.html |archive-date=February 9, 2014 |access-date=December 17, 2013 |publisher=Agile Alliance}}</ref>
===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.{{cn|date=December 2025}}
== See also ==
* {{Annotated link |Agile software development}} ** {{Annotated link |Agile testing}} * {{Annotated link |Agile learning}} * {{Annotated link |Disciplined agile delivery}} * {{Annotated link |Comparison of scrum software}} * {{Annotated link |High-performance teams}} * {{Annotated link |Lean software development}} * {{Annotated link |Project management}} * {{Annotated link |Unified process}}
== Citations == {{reflist}}
== General and cited references == {{Refbegin}} * {{Cite journal |last1=Janoff |first1=N. S. |last2=Rising |first2=L. |year=2000 |title=The Scrum Software Development Process for Small Teams |pages=26-32 |url=https://web.archive.org/web/20151106053048/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/scrum/s4026.pdf |journal=IEEE Software |volume=17 |issue=4 |doi=10.1109/52.854065 }} * {{Cite book |last1=Münch |first1=Jürgen |title=Software Process Definition and Management |last2=Armbrust |first2=Ove |last3=Soto |first3=Martín |last4=Kowalczyk |first4=Martin |year=2012 |publisher=Springer |isbn=978-3-642-24291-5}} * {{Cite book |title=A guide to the project management body of knowledge (PMBOK guide) |edition=7th |location=Newtown Square, PA |publisher=Project Management Institute |date=2021 |isbn=978-1-62825-664-2 |ref={{sfnref|Project Management Institute|2021}} }} * {{Cite web |last=Vacaniti |first=Daniel |date=February 2018 |title=The Kanban Guide for Scrum Teams |url=https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-02/2018%20Kanban%20Guide%20for%20Scrum%20Teams_0.pdf |website=scrum.org |access-date=March 12, 2018 }} {{refend}}
== External links == {{Commons category|Scrum (development)}} {{Wikisource|The Scrum Guide}} {{Prone to spam|date=May 2015}} <!-- {{No more links}}
Please be cautious adding more external links.
Wikipedia is not a collection of links and should not be used for advertising.
Excessive or inappropriate links will be removed.
See Wikipedia:External links and Wikipedia:Spam for details.
If there are already suitable links, propose additions or replacements on the article's talk page. --> * [http://cf.agilealliance.org/articles/article_list.cfm?CategoryID=17 Agile Alliance's Scrum library] * [https://web.archive.org/web/20170605114816/http://epf.eclipse.org/wikis/scrum/ A scrum process description] by the Eclipse process framework (EPF) project
{{Software engineering}} {{Authority control}}
Category:Agile software development Category:Software development Category:Software development philosophies Category:Software project management