Scrum (software development): Difference between revisions

Revision as of 03:13, 5 June 2009

Latest revision as of 15:22, 15 August 2025

Line 1:

{{Short description|Management framework}}

{{otheruses|Scrum}}

{{About|software development framework||Scrum (disambiguation){{!}}Scrum}}

[[File:Scrum process.svg|thumb|400px|right|The Scrum process.]]

{{Multiple issues|{{More citations needed|date=May 2020}}

{{Software development process}}

{{Unreliable sources|date=May 2020}}}}

'''Scrum''' is an iterative incremental framework for managing complex work (such as new product development) commonly used with [[agile software development]]. Despite the fact that "Scrum" is not an acronym, some companies implementing the process have been known to adhere to an all capital letter expression of the word, i.e., SCRUM. This may be due to one of [[Ken Schwaber]]'s early papers capitalizing SCRUM in the title.<ref name="schwaber">{{cite book|title=Agile Project Management with Scrum|last=Schwaber|first=Ken|authorlink=Ken Schwaber|publisher=[[Microsoft Press]]|isbn=978-0-735-61993-7|date=1 February 2004}}</ref>

{{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" />]]

'''Scrum''' is an [[Agile management|agile]] team collaboration framework commonly used in [[software development]] and other industries.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.

Scrum prescribes for teams to break work into [[goal]]s to be completed within [[Timeboxing|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 meeting|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 [[Stakeholder (corporate)|stakeholders]] and solicit feedback, and one internal [[Retrospective#Software development|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>

== History ==

In 1986, [[Hirotaka Takeuchi]] and [[Ikujiro Nonaka]] described a new [[holistic]] approach that increases speed and flexibility in commercial [[new product development]].<ref>{{cite journal|url=http://apln-richmond.pbwiki.com/f/New%20New%20Prod%20Devel%20Game.pdf|format=PDF|title=The New New Product Development Game|last=Takeuchi|first=Hirotaka|authorlink=Hirotaka Takeuchi|coauthors=Nonaka, Ikujiro|journal=Harvard Business Review|year=1986|month=January-February|accessdate=2008-09-26}}</ref> They compare this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, to [[Rugby union|rugby]], where the whole team "tries to go to the distance as a unit, passing the ball back and forth". The case studies come from the automotive, photo machine, computer and printer industries.

Scrum's approach to product development involves bringing [[decision-making]] authority to an operational level.<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> Unlike a sequential approach to product development, scrum is an [[Iterative design|iterative]] and [[Iterative and incremental development|incremental]] framework for product development.<ref name="scrumalliance">{{cite web |title=What is Scrum? |url=https://www.scrumalliance.org/why-scrum |access-date=February 24, 2016 |website=What is Scrum? An Agile Framework for Completing Complex Projects – Scrum Alliance |publisher=Scrum Alliance}}</ref> Scrum allows for continuous feedback and flexibility, requiring teams to self-organize by encouraging physical [[Colocation (business)|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>

In 1991, DeGrace and Stahl, in ''Wicked Problems, Righteous Solutions'',<ref>{{cite book|title=Wicked problems, righteous solutions|last=DeGrace|first=Peter|coauthors=Stahl, Leslie Hulet|date=1 October 1990|isbn=978-0-135-90126-7|publisher=Prentice Hall}}</ref> referred to this approach as [[Scrum (rugby)|Scrum]], a rugby term mentioned in the article by Takeuchi and Nonaka. In the early 1990s, [[Ken Schwaber]] used an approach that led to Scrum at his company, Advanced Development Methods. At the same time, [[Jeff Sutherland]], John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and was the first to call it Scrum.<ref>{{cite web|url=http://jeffsutherland.com/scrum/FirstScrum2004.pdf|format=PDF|title=Agile Development: Lessons learned from the first Scrum|last=Sutherland|first=Jeff|authorlink=Jeff Sutherland|year=2004|month=October|accessdate=2008-09-26}}</ref> In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at [[OOPSLA|OOPSLA '95]] in Austin, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber teamed up with Mike Beedle to write up the method in the book ''Agile Software Development with Scrum''.

{{TOC limit|3}}

== Characteristics ==

Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main roles in Scrum are: (1) the "ScrumMaster," who maintains the processes (typically in lieu of a project manager); (2) the "Product Owner," who represents the stakeholders; and (3) the "Team", a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

== History ==

During each "[[Sprint (software development)|sprint]]", typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product "backlog", which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.<ref name="schwaber" /> During a sprint, no one is allowed to change the sprint backlog, which means that the [[requirement]]s are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.

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 [[economic sector|industries]], the authors outlined a new approach to product development for increased speed and flexibility. They called this the [[Rugby football|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" />

Scrum enables the creation of self-organizing teams by encouraging co-___location of all team members, and verbal communication across all team members and disciplines that are involved in the project.

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.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

== Scrum team ==

There are several implementations of systems for managing the Scrum process, which range from yellow stickers and whiteboards, to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.

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>

=== RolesProduct 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 [[Stakeholder (corporate)|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 |page=173 |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><ref>{{cite web |last=Ambler |first=Scott |title=The Product Owner Role: A Stakeholder Proxy for Agile Teams |url=http://agilemodeling.com/essays/productOwner.htm |access-date=July 22, 2016 |publisher=agilemodeling.com |quote=[...] 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.}}</ref> Product owners manage the [[product backlog]] and are responsible for maximizing the value that a team delivers.<ref name=":3" /> They do not dictate the technical solutions of a team but may instead attempt to seek consensus among team members.<ref name="scrumguidepdf2016">{{cite web |title=The Scrum Guide |url=https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf |access-date=June 15, 2023 |publisher=Scrum.org |page=6}}</ref><ref>{{cite web |title=The Role of the Product Owner |url=https://resources.scrumalliance.org/Webinar/the-role-of-the-product-owner/ |access-date=May 26, 2018 |publisher=Scrum Alliance}}</ref>

{{main|The Chicken and the Pig}}

A number of roles are defined in Scrum. All roles fall into two distinct groups--[[pig]]s and [[chicken]]s--based on the nature of their involvement in the development process. These groups get their names from a joke about a pig and a chicken opening a restaurant:<ref name="schwaberp7">Schwaber, p. 7</ref>

<blockquote>

A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed, but you'd only be involved."

</blockquote>

As the primary liaison of the scrum team towards stakeholders, product owners are responsible for communicating announcements, project definitions and progress, RIDAs ([[Project risk management|risks]], impediments, [[Dependency (project management)|dependencies]], and assumptions), funding and scheduling changes, the product backlog, and project governance, among other responsibilities.<ref>{{cite web |title=The Product Owner Role |url=http://scrum-master.thinkific.com/pages/the-product-owner-role |website=Scrum Master Test Prep |access-date=February 3, 2017}}</ref>{{Better source needed|reason=The current source is insufficiently reliable ([[WP:NOTRS]]).|date=July 2023}} Product owners can also cancel a sprint if necessary, without the input of team members.<ref name="scrumguidesite" />

So the "pigs" are committed to building software regularly and frequently, while everyone else is a "chicken" - interested in the project but really indifferent because if it fails they're not the pigs - that is, they weren't the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

=== "Pig" rolesDevelopers ===

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, [[systems architect |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>

The Pigs are the ones committed to the project in the Scrum process - they are the ones with "their bacon on the line."

=== Scrum master ===

; Product Owner

Scrum is facilitated by a scrum master, whose role is to educate and coach teams about scrum theory and practice.<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 masters have differing roles and responsibilities from traditional [[team leader|team leads]] or [[project manager|project managers]]. Some scrum master responsibilities include coaching, objective setting, problem solving, oversight, planning, backlog management, and communication facilitation.<ref name="scrumguidepdf2020" /> On the other hand, traditional project managers often have [[Management|people management]] responsibilities, which a scrum master does not. Scrum teams do not involve project managers, so as 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>

: The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the "right things" from a business perspective. The Product Owner writes customer-centric items (typically [[User story|user stories]]), prioritizes them and then places them in the [[#Product_backlog|product backlog]].

== Workflow ==

; ScrumMaster (or Facilitator)

=== Sprint ===

: Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the team and keep them focused on the tasks in hand<!-- and sprints of practice [removed because unclear] -->.

{{Distinguish|Hackathon#Code sprints}}

[[File:Scrum Framework.png|thumb|right|The scrum framework (PBI in the figure refers to product backlog item)]]

[[File:Scrum process.svg|thumb|The scrum process]]

A sprint (also known as a ''[[design sprint]]'', ''[[Iterative and incremental development|iteration]]'', or ''[[Timeboxing|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.<ref name="schwaber" /> The outcome of the sprint is a functional deliverable, or a product which has received some development in [[Iterative and incremental development|increments]]. When a sprint is abnormally terminated, the next step is to conduct new sprint planning, where the reason for the termination is reviewed.

Each sprint starts with a sprint planning event in which a sprint goal is defined. Priorities for planned sprints are chosen out of the backlog. Each sprint ends with two events:<ref name="autogenerated1" />

; Team

: The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

* A ''sprint review'' (progress shown to stakeholders to elicit their feedback)

=== "Chicken" roles ===

* A ''sprint retrospective'' (identifying lessons and improvements for the next sprints)

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an [[Agile software development|Agile]] approach is the practice of involving users, internal business groups and stakeholders into portions of the process. It is important for these people to be engaged in the outcome of the project by providing feedback into the development, its review and planning for each sprint.

The suggested maximum duration of sprint planning is eight hours for a four-week sprint.<ref name="scrumguidesite" />

; Users

: People the software is being built for.

===Daily scrum===

; Stakeholders (customers, vendors)

{{Main|Daily scrum meeting}}

: These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

[[File:Daily sprint meeting.jpg|thumb|A daily scrum in the computing room]]

; Managers

Each day during a sprint, the developers hold a daily scrum (often conducted [[stand-up meeting|standing up]]) with specific guidelines, and which may be facilitated by a scrum master.<ref name="schwaber" /><ref>{{cite web |title=What is a Daily Scrum? |url=https://www.scrum.org/resources/what-is-a-daily-scrum |website=Scrum.org |access-date=January 6, 2020}}</ref> 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>

: People who will set up the environment for the product development organizations.

===Post-sprint events===

== Meetings ==

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="scrumguidesite" />

; Daily Scrum

:Each day during the sprint, a project status meeting occurs. This is called a "scrum", or "the daily standup". The scrum has specific guidelines:

:* The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)

:* All are welcome, but only "pigs" may speak

:* The meeting is [[timebox]]ed to 15 minutes

:* All attendees should stand (it helps to keep meeting short)

:* The meeting should happen at the same ___location and same time every day

:During the meeting, each team member answers three questions:<ref name="schwaberp135">Schwaber, p. 135</ref>

:* What have you done since yesterday?

:* What are you planning to do by today?

:* Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)

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 [[Continual improvement process|continuous process improvement]] actions.<ref name="Essential Scrum: Velocity2">{{Citation |last=Rubin |first=Kenneth |title=Essential Scrum. A Practical Guide to the Most Popular Agile Process |page=375 |publication-date=2013 |year=2012 |publisher=Addison-Wesley |language=EN |isbn=978-0-13-704329-3}}</ref>

; Sprint Planning Meeting<ref name="schwaberp133">Schwaber, p. 133</ref><ref>{{cite journal|url=http://www.sprintplanning.com/SprintPlanningRules.aspx|format=html|title=Sprint Planning Rules|last=Sprint|first=Planning|year=2009|month=January-February|accessdate=2009-03-30}}</ref>

:At the beginning of the sprint cycle (every 15–30 days), a "Sprint Planning Meeting" is held.

:* Select what work is to be done

:* Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team

:* Identify and communicate how much of the work is likely to be done during the current sprint

:* Eight hour limit

=== Backlog grooming or refinement ===

:At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint [[Retrospective#Software engineering|Retrospective]]"

Backlog grooming or refinement is a process by which team members revise and prioritize a backlog for future sprints.{{sfn|Project Management Institute|2021|loc=Glossary §3 Definitions}} 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=Atlassian |date= |title=What is backlog grooming? Definition and benefits |url=https://www.atlassian.com/agile/project-management/backlog-grooming |website=atlassian.com |language=en |publisher=Atlassian |access-date=2025-06-17 |quote=Backlog grooming, or backlog refinement, is the regular updation of the product backlog.}}</ref>

== Artifacts ==

; Sprint Review Meeting<ref name="schwaberp137">Schwaber, p. 137</ref>:

{{more citations needed section|date=March 2013}}

:* Review the work that was completed and not completed

[[Artifact (software development)|Artifact]]s are a means by which scrum teams manage product development by documenting work done towards the project. There are seven scrum artifacts, with three of them being the most common: product backlog, sprint backlog, and increment.<ref>{{Cite web |title=What are Scrum Artifacts? {{!}} The Ultimate Guide {{!}} Miro |url=https://miro.com/agile/what-are-scrum-artifacts/ |access-date=2024-11-29 |website=miro.com/ |language=en-US}}</ref>

:* Present the completed work to the stakeholders (a.k.a. "the demo")

:* Incomplete work cannot be demonstrated

:* Four hour time limit

; Sprint Retrospective<ref name="schwaberp138">Schwaber, p. 138</ref>:

:* All team members reflect on the past sprint.

:* Make continuous process improvement.

:* Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

:* Three hour time limit

== Artifacts ==

=== Product backlog ===

{{main|Product backlog}}

The product backlog is a breakdown of work to be done and contains an ordered list of [[Requirement|product requirements]] (such as [[Software feature|feature]]s, [[Patch (computing)|bug fix]]es and [[non-functional requirement]]s) that the team maintains for a [[New product development|product]]. The order of a product backlog corresponds to the urgency of the task. Common formats for backlog items include [[user story|user stories]] and [[use case]]s.<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 [[Planning poker|story points]] using the rounded [[Fibonacci sequence|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>

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.<ref name="schwaber" />

The '''product backlog''' is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the "What" that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the "add spellcheck" and "add table support" features have the same business value, the one with the smallest development effort will probably have higher priority, because the [[return on investment|ROI]] is higher.

===Sprint backlog===

The product backlog is property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.

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. Team members self organize by pulling work as needed according to the backlog priority and their own capabilities and capacity.<ref name="scrumguidepdf2017">{{cite web |author=[[Ken Schwaber]] |author2=[[Jeff Sutherland]] |title=The Scrum Guide |url=http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf |access-date=May 25, 2018 |publisher=Scrum.org}}</ref>

=== Sprint backlogIncrement ===

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.

The '''sprint backlog''' is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.

=== Other artifacts ===

The sprint backlog is property of the Team. Estimations are set by the Team. Often an according '''Task Board''' is used to see and change the state of the tasks of the current sprint, like "to do", "in progress" and "done".

==== Burndown chart ====

[[File:SampleBurndownChart.svg|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.

=== Burn down ===

The [[burn down chart]] is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

==== Release burnup chart ====

It should not be confused with an [[Earned value management|earned value 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.

==== Velocity ====

== Adaptive project management ==

{{main|Velocity (software development)}}

The following are some general practices of Scrum:

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 (software development)|velocity]]" data is a guideline for assisting the team in understanding their capacity.

* Customers become a part of the development team (i.e., the customer must be genuinely interested in the output.)

* Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.

* Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.

* Transparency in planning and module development—let everyone know who is accountable for what and by when.

* Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)

* There should be an advance warning mechanism, i.e., visibility to potential slippage or deviation ahead of time.

* No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.

* Workplaces and working hours must be energized—"Working more hours" does not necessarily mean "producing more output."

== TerminologyLimitations ==

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 web |last=Jenson |first=John |date=March 8, 2019 |title=Meetings: The productivity killer for developers |url=https://www.tandemseven.com/blog/meetings-productivity-killer-for-developers/ |archive-url=https://web.archive.org/web/20200605155907/https://www.tandemseven.com/blog/meetings-productivity-killer-for-developers/ |archive-date=2020-06-05 |access-date=June 5, 2020 |website=TandemSeven – The Experience Innovation Company}}</ref><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>

The following terminology is used in Scrum:<ref name="schwaberp141-143">Schwaber, pp. 141–143</ref>

=== RolesAdaptations ===

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|page=111110|doi=10.1016/j.jss.2021.111110|s2cid=240950847 |issn=0164-1212}}</ref> A common approach to adapting scrum is the combination of scrum with other software development methodologies, as scrum does not cover the whole [[software lifecycle|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=http://pure.au.dk/portal/files/116906219/Hron_Obwegeser_Scrum_in_practice_An_overview_of_Scrum_adaptations.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 pattern]]s 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}}</ref><ref>{{cite web |title=Scrum Pattern Community |url=http://www.scrumplop.org |website=ScrumPLoP.org |access-date=July 22, 2016}}</ref>

; Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.

; ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.

; Team: A cross-functional group of people responsible for managing itself to develop the product.

; Scrum Team: Product Owner, ScrumMaster and Team

=== ArtifactsScrumban ===

{{Main|Scrumban}}

; Sprint burn down chart: Daily progress for a Sprint over the sprint's length.

Scrumban is a software production model based on scrum and [[Kanban (development)|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>

; Product backlog: A prioritized list of high level requirements.

; Sprint backlog: A prioritized list of tasks to be completed during the sprint.

=== OthersScrum 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>{{cite web |title=Risk Management – How to Stop Risks from Screwing Up Your Projects! |url=http://www.allaboutagile.com/risk-management-how-to-stop-risks-from-screwing-up-your-projects/ |publisher=Kelly Waters}}</ref><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>

; Impediment: Anything that prevents a team member from performing work as efficiently as possible.

; Sprint: A time period (typically between two weeks and one month) in which development occurs on a set of backlog items that the Team has committed to.

; Sashimi: A slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done.

; Velocity: How much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.

===Large-scale scrum===

== Software tools ==

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]].<ref>{{cite web |year=2014 |title=Large-Scale Scrum (LeSS) |url=http://less.works}}</ref><ref>{{cite web |last=Grgic |year=2015 |title=Descaling organisation with LeSS (Blog) |url=https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html}}</ref> 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.<ref>{{cite periodical |title=Scaling Agile Development |periodical=Crosstalk |date=May–June 2013 |url=http://www.crosstalkonline.org/storage/issue-archives/2013/201305/201305-larman.pdf |last1=Larman, Craig |author2=Bas Vodde}}</ref>

Although the process itself requires no software at all, quite a lot of software applications were published in the last years that should support the scrum roles. Typically these tools improve backlog handling and generate burndown charts automatically. Among the well-known tools are:

* [[Agilo for Scrum]]

* [[Banana Scrum]]

== Criticism ==

However most people recommend that Scrum teams should use no software tools because they may prevent communication and they require additional knowledge while everyone can handle stickies immediately.

{{stub section|date=June 2024}}

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 (software engineer)|Martin Fowler]], one of the authors of the [[Agile software development#The Agile Manifesto|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.

== Extended usage ==

Though Scrum was originally applied to software development only, it can also be successfully used in other industries. Now Scrum is often viewed as an iterative, incremental process for developing any product or managing any work.

In September 2016, Ron Jeffries, a signatory to the [[Agile software development|Agile Manifesto]],<ref name="agilemanifesto" /> described what he called "Dark Scrum", saying that "Scrum can be very unsafe for programmers."<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>

=== Product development ===

Scrum as applied to product development was first referred to in "[http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id=86116 The New New Product Development Game]" (Harvard Business Review 86116:137–146, 1986) and later elaborated in "[http://books.google.ru/books?hl=en&id=B-qxrPaU1-MC&dq=The+Knowledge+Creating+Company&printsec=frontcover&source=web&ots=XfRLlzreeT&sig=B5tPPUD6s-hBTlmi4cQLVYosoWs The Knowledge Creating Company]" both by Ikujiro Nonaka and [[Hirotaka Takeuchi]] (Oxford University Press, 1995). Today there are records of Scrum used to produce financial products, Internet products, and medical products by ADM.

=== Marketing project management methodology ===

As [[marketing]] is often executed in a project-based manner, a lot of generic project management principles apply to marketing. Marketing can also be optimized similar to [[project management]] techniques. [http://www.wrike.com/projectmanagement/11/27/2007/Scrum-in-marketing-making-enterprises-adaptive Scrum approach to marketing] is believed to be helpful for overcoming problems experienced by marketing executives. Short and regular meetings are important for small marketing teams, as every member of a team has to know what the others are working on and what direction the whole team is moving in. Scrum in marketing makes it possible to:

* See possible problems at early stages and allows coping with them quicker and with minimal losses. According to the key principle of Scrum "no problems are swept under the carpet", every team member is encouraged to describe the difficulties he is experiencing, as this might influence the work of the whole group.

* Reduce financial risk. With the beginning of every sprint period, the business owner can change any of the marketing project parameters without penalty, including increasing investments to enlarge consumers' quantity, reducing investments until unknowns are mitigated, or financing other initiatives.

* Make marketing planning flexible. Short-term marketing plans based on sprints can be much more effective. Marketing managers get an opportunity to switch from one promotion method to another, if the first one proved to be unsuccessful during the sprint period. It also becomes easier to clarify due dates of every small, but important, task to each member of a team.

* Involve clients in various ways.

There is also a tendency to execute Scrum in marketing with the help of [[Enterprise 2.0]] technologies and [[Project management 2.0]] tools.

== See also ==

* [[Agile software development]]

* [[Kaizen]]

** [[Agile testing]]

* [[List of software development philosophies]]

* [[CowboyAgile codinglearning]]

* [[Disciplined agile delivery]]

* [[Comparison of scrum software]]

;Other Agile methods

* [[High-performance teams]]

* [[DSDM|Dynamic System Development Method]]

* [[Feature Driven Development]]

* [[Extreme programming]] (XP)

* [[Lean software development]]

* [[Project management]]

* [[Unified process]]

== ReferencesCitations ==

{{reflist}}

== General and cited references ==

== Videos ==

{{Refbegin}}

* [http://video.google.com/videoplay?docid=8795214308797356840 Jeff Sutherland in ''Scrum Tuning: Lessons learned from Scrum implementation at Google''] Retrieved [[2007-12-15]]

* {{Cite web |last1=Deemer |first1=Pete |last2=Benefield |first2=Gabrielle |last3=Larman |first3=Craig |last4=Vodde |first4=Bas |year=2009 |title=The Scrum Primer |url=http://www.scrumprimer.org |access-date=June 1, 2009}}

* [http://video.google.com/videoplay?docid=2531954797594836634 Ken Schwaber in ''Scrum et al.''] Retrieved [[2008-01-19]]

* {{Cite web |last1=Janoff |first1=N. S. |last2=Rising |first2=L. |year=2000 |title=The Scrum Software Development Process for Small Teams |url=http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/scrum/s4026.pdf |access-date=February 26, 2015 |archive-date=November 6, 2015 |archive-url=https://web.archive.org/web/20151106053048/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/scrum/s4026.pdf }}

* [http://www.youtube.com/watch?v=Ht2xcIJrAXo Jeff Sutherland in ''Hyperproductive Distributed Scrum Teams'']

* {{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}}

* [http://www.youtube.com/watch?v=Q5k7a9YEoUI&fmt=22 Hamid Shojaee in ''Scrum in 10 Minutes'' (High Quality HD Video)]

* {{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}} }}

* [http://www.youtube.com/watch?v=M1q6b9JI2Wc Jeff Sutherland in ''Self-Organization: The Secret Sauce for Improving your Scrum team'']

* {{Cite book |last=Rubin |first=Kenneth |date=2013 |title=Essential Scrum: A Practical Guide to the Most Popular Agile Process |publisher=Addison-Wesley |page=173 |language=EN |isbn=978-0-13-704329-3}}

* [https://jazz.net/pub/learn/videos/data/Scrum-RTC-Video/Scrum-RTC-Video-cleared.html Millard Ellingsworth in ''Using the Scrum Process and Agile Estimating and Planning with Rational Team Concert'']

* {{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 }}

* [http://www.vimeo.com/4587652 Bruno Sbille and his team in ''Scrum applied on a real-world project'' (HD)] Retrieved [[2009-05-19]]

* Verheyen, Gunther (2013). ''Scrum – A Pocket Guide (A Smart Travel Companion)''. {{ISBN|978-90-8753-720-3}}.

{{Refend}}

== External links ==

{{Commons category|Scrum (development)}}

<!--===========================({{NoMoreLinks}})===============================-->

{{Wikisource|The Scrum Guide}}

<!--| DO NOT ADD MORE LINKS TO THIS ARTICLE. WIKIPEDIA IS NOT A COLLECTION OF |-->

{{Prone to spam|date=May 2015}}

<!--| LINKS. If you think that your link might be useful, do not add it here, |-->

<!-- {{No more links}}

<!--| but put it on this article's discussion page first or submit your link |-->

<!--| to the appropriate category at the Open Directory Project (www.dmoz.org)|-->

<!--| and link back to that category using the {{dmoz}} template. |-->

<!--| |-->

<!--| Links that have not been verified WILL BE DELETED. |-->

<!--| See [[Wikipedia:External links]] and [[Wikipedia:Spam]] for details |-->

<!--===========================({{NoMoreLinks}})===============================-->

{{Commonscat|Scrum}}

* [http://www.scrumalliance.org/ Scrum Alliance]

* [http://www.agilealliance.org/article/articles_by_category/17 Agile Alliance's Scrum library]

* [http://members.cox.net/risingl1/Articles/IEEEScrum.pdf (PDF) Rising, L., Janoff, N.S. (2000). ''The Scrum Software Development Process for Small Teams''] Retrieved [[March 15]], [[2007]]

* [http://jeffsutherland.com/oopsla/schwapub.pdf (PDF) Schwaber, K. Advanced Development Methods. ''SCRUM Development Process''] Retrieved [[August 15]], [[2006]]

Please be cautious adding more external links.

{{Software Engineering}}

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}}

<!-- Categories -->

[[Category:Agile software development]]

[[Category:ManagementSoftware development]]

[[Category:Production and manufacturing]]

[[Category:Project management]]

[[Category:Software development philosophies]]

[[Category:Software project management]]

<!-- Interwikis -->

[[bg:Scrum]]

[[da:Scrum]]

[[de:Scrum]]

[[es:Scrum]]

[[fr:Scrum]]

[[ko:스크럼 (애자일 개발 프로세스)]]

[[it:Scrum]]

[[he:Scrum]]

[[lt:Scrum]]

[[hu:Scrum]]

[[nl:Scrum (softwareontwikkelmethode)]]

[[ja:スクラム (ソフトウェア開発)]]

[[no:Scrum]]

[[pl:Scrum]]

[[pt:Scrum]]

[[ru:Scrum]]

[[sh:Scrum]]

[[fi:Scrum]]

[[sv:Scrum]]

[[uk:Scrum]]

[[zh:Scrum]]