Wikipedia

Scrum (software development): Difference between revisions

Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
 
Line 1:
{{Short description|Management framework}}
{{Merge|Scrum (management)|date=July 2006}}
{{About|software development framework||Scrum (disambiguation){{!}}Scrum}}
{{Wikify|October 2006}}
{{Multiple issues|{{More citations needed|date=May 2020}}
{{Unreliable sources|date=May 2020}}}}
{{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.
[[Scrum (management)|Scrum]] is a lightweight [[Agile software development|agile method]] for software development. Scrum is named after the [[Scrum (rugby)|scrum]] in [[Rugby football|rugby]], which is a way to restart the game after an accidental infringement. This entry describes the software development part of Scrum. This means that subjects like Scrum [[project planning]], time/costs/risk management will not be explained in this entry.
 
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>
Scrum was first applied in 1993 at [[Easel Corporation]] by Jeff Sutherland, John Scumniotales and Jeff McKenna when building an [[object-oriented]] design and analysis ([[OOAD]]) tool incorporating [[Round-trip engineering]]. At that time they needed a development method that had [[rapid application development]] and where product requirements could easily be translated into working code. These principles later became some of the basics of Scrum.
 
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>
Some companies that applied variants of the Scrum approach for their projects are [[Fuji-Xerox]], [[Canon (company)|Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother Industries|Brother]], [[3M]], [[Xerox]] and [[Hewlett-Packard]]. These projects were observed and the results were published by Takeuchi and Nonaka in the ''[[Harvard Business review]]'' as “The New New Product Development Game” (January-February 1986).
 
{{TOC limit|3}}
==Characteristics of Scrum software development process==
Scrum assumes that the software development process is complicated and unpredictable and treats it as a controlled black box instead of a theoretical, fully defined process. This is one of the biggest differences between Scrum and the [[Waterfall model|Waterfall]] and [[Spiral model|Spiral]] methodologies, which view the software development process as a fully defined process.
Most problems encountered when using these older, formal types of methodologies are :
*Requirements are '''not fully understood''' at the beginning of the process.
*Requirements '''change during the process'''.
*The process becomes '''unpredictable when new tools and technologies''' are used.
 
== History ==
Another characteristic of Scrum is that the software development process isn’t treated as a linear process, unlike the Waterfall, Spiral and Iterative methodologies. In a lot of cases this linear process consists of the following four activities: Analysis, Design, Implementation and Testing.
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>
Scrum, however, doesn't prescribe a sequence in which the activities must be implemented. A project can start with any activity, and can change between activities at any time. This increases the project's flexibility and productivity.
Other characteristics of Scrum are:
*Flexible schedules
*Flexible deliverables
*Small teams
*Frequent reviews
*Object orientation
*Collaboration between and within teams
 
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" />
Other characteristics that Scrum shares with rugby are:
*The environment determines the process (the game)
*The environment (functionality, timetable, business need and competition) dictates the ending of the process (the game).
*“Rugby evolved from breaking soccer rules – adapting to the environment.” (Schwaber, K.)
*“The primary cycle is moving the ball forward” (Schwaber, K.)
To manage these processes with flexibility, Scrum supplies techniques and controls to manage this unpredictable process. Techniques will be explained in “Techniques” and controls will be explained in “Scrum controls”.
 
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.
==The Scrum development phase==
===Techniques===
These are techniques that are needed for the Scrum development phase.
 
====Team creation==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>
Scrum believes that a development team should perform as a sport team, every team member working independently but towards the same goal. Scrum suggests that a team has a maximum of 6 - 7 members. The team facilitator is called the Scrum master. His/her job is to implement and manage the Scrum process in the project. The Scrum team as a whole defines the practices, meetings, artifact and terminology of SCRUM for the team, and the Scrum Master ensures adherence to these "norms" identified. Scrum masters serve a facilitator role and their authority is mostly indirect. Scrum masters focus most of their time in managing outside interference for the Scrum team and solving outside impediments or ‘Blockers’ that cannot be solved by the Scrum team. The master also focuses on ensuring transparency into the development process by maintaining the multiple Scrum artifacts defined elsewhere in this article.
 
====Backlog creation=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 [[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>
There are three backlog types:
#Product Backlog - Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders.
#Release Backlog - Requirements pulled from the product backlog and identified and prioritized for an upcoming release. The release backlog contains more details about the requirement and low level estimate which are usually estimated by the team performing the work.
#Sprint Backlog - At the beginning of each sprint, the team has sprint planning with an end result being a backlog of requirements/sub-requirements that the team anticipates completing at the end of the sprint. By completing, that means fully coded, tested and documented. These are the items that the team will "Burndown" throughout the duration of the sprint.
 
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" />
The sprint backlog breaks the release backlog requirement into manageable chunks that can be accomplished typically in 8 - 16 hrs.
 
====Project segmentation=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, [[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 whole project gets divided into periods of time with a maximum duration of 4 weeks. One period is called a Sprint and every team gets a backlog to execute within the given Sprint.
 
==== Scrum meetings=master ===
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>
* During the sprint, the team conducts daily scrum meetings.
* The meetings are held in the same place at the same time every work day.
* The meetings don’t last for more than 30 minutes.
* A scrum master is appointed.
* The scrum master is responsible for asking every team member the following three questions:
# What have you done since the last scrum meeting?
# What has impeded your work?
# What do you plan on doing between now and the next scrum meeting?
* Conversation is restricted to the team members answering the above questions.
* Meetings can be established for immediately after the scrum meeting based on answers to the above questions.
* The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.
* The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.
 
===Phases= Workflow ==
=== Sprint ===
The Scrum development process consists of 5 major activities “Review release plans”, “Distribution, review and adjustment of product standards”, “Sprint”, “Sprint review” and “Closure”.
{{Distinguish|Hackathon#Code sprints}}
Image 1 ([[Meta-modeling|Meta process model]]) gives an interpretation of these activities.
[[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" />
====Sprint====
The Sprint phase is where the software development takes place.
A Sprint consists of the following sub-activities: Develop, Wrap, Review and Adjust.
This phase has no sequence. Sometimes a backlog item must be developed, wrapped and reviewed and sometimes a backlog item must be only reviewed or adjusted. It totally depends on the backlog item.
See “Extended information about activities and sub activities” for further explanation of these sub activities..
 
* A ''sprint review'' (progress shown to stakeholders to elicit their feedback)
====Sprint review====
* A ''sprint retrospective'' (identifying lessons and improvements for the next sprints)
Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added. The reviewers consist of project stakeholder, managers, developers and sometimes customers, sales and marketing.
 
The suggested maximum duration of sprint planning is eight hours for a four-week sprint.<ref name="scrumguidesite" />
The activities, Sprint and Sprint review are repeated until the product is deemed ready for distribution by the project stakeholders. Then the project goes into the closure phase where the product is made ready for release and distribution.
 
====Closure=Daily scrum===
{{Main|Daily scrum meeting}}
In this stage activities like last debugging, marketing and promotion take place.
By finishing this activity the project is closed. Because of the unpredictability of the software development process it’s not possible to define exactly when this activity will take place and so the project may take shorter or longer than planned.
But by using the controls given by Scrum one can make calculations on the duration of the project. More about controls and this kind of calculation can be found in the “Scrum Controls” part.
 
[[File:Daily sprint meeting.jpg|thumb|A daily scrum in the computing room]]
====Extended information about activities and sub activities====
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>
{|
| valign='top' | [[Image:Meta process model.GIF]]||
{| class="wikitable"
|-
| width='60' | '''Activity'''
| '''Sub-Activity'''
| '''Description'''
|-
| colspan='2' | '''Review release plans'''
| Reviewing of the release plans
|-
| colspan='2' | '''Distribution , review and adjustment of product standards'''
| “Distribution, review and adjustment of the standards with which the product will conform.”(Schwaber, K.)
|-
| colspan='2' | '''SPRINT'''
| “The Development phase is an iterative cycle of development work. The management determines that time, competition, quality, or functionality are met, iterations are completed and the closure phase occurs.” (Schwaber, K.)
|-
|
| Develop
| “Defining changes needed for the implementation of backlog requirements into packets, opening the packets, performing ___domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation.” (Schwaber, K.)
|-
|
| Wrap
| “Closing the packets, creating an executable version of changes and how they implement backlog requirements.” (Schwaber, K.)
|-
|
| Review
| “All teams meeting to present work and review progress, raising and resolving issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined.” (Schwaber, K.)
|-
|
| Adjust
| “Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.” (Schwaber, K.)
|-
| colspan='2' | '''SPRINT Review'''
| Each Sprint is followed by a review.
|-
|
| Review the software
| “The whole team and product management are present and participate. The review can include customers, sales, marketing and others.Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items.” (Schwaber, K.)
|-
|
| Compare backlog with the developed software
| “Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items.” (Schwaber, K.)
|-
|
| Editing of the backlog
| “The way backlog items are implemented by changes may be changed based on the review.”(Schwaber, K.)
|-
|
| Add new backlog items &Assign backlog items to teams
| “New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables.”(Schwaber, K.)
|-
|
| Plan next review
| “The time of the next review is determined based on progress and complexity. The Sprints usually have duration of 1 to 4 weeks.” (Schwaber, K.)
|-
| colspan='2' | '''Closure'''
| “When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.” (Schwaber, K.)
|}
|}
 
===Post-sprint events===
==Controls==
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" />
To be able to manage the black box called the development process, Scrum supplies controls. These controls are products of the Scrum techniques and project’s progression.
By studying these results decisions can be made by the project manager.
For example:
*The number of backlog items defines the size of the project.
*By counting the successfully finished backlogs the manager has a way to measure the project progression.
*The amount of risks defines the complexity of the project.
 
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>
The following image (Meta data model) shows how these controls are connected to each other and what influence they have on each other. This Meta data model is followed by a table explaining each control.
 
=== Backlog grooming or refinement ===
===Meta data model===
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>
[[Image:Scrum development meta data model.GIF]]
<TABLE border=1 style='border-collapse: collapse;'>
<TR>
<TD>'''Concept'''</TD>
<TD>'''Definition(source)'''</TD>
</TR>
<TR>
<TD>'''CONTROL'''</TD>
<TD>“A control mechanism is used to manage the unpredictability and control the risk.” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''BACKLOG'''</TD>
<TD>“Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items. ” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''BACKLOG ITEM'''</TD>
<TD>An item on the BACKLOG list.</TD>
</TR>
<TR>
<TD>'''RELEASE'''</TD>
<TD>“Backlog items that at a point in time represent a viable release based on the variables of requirements, time, quality, and competition.”(Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''PACKET'''</TD>
<TD>“Product components or objects that must be changed to implement a backlog item into a new release.” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''PRODUCT COMPONENT / OBJECT'''</TD>
<TD>A small part of the software</TD>
</TR>
<TR>
<TD>'''CHANGE'''</TD>
<TD>“Changes that must occur to a packet to implement a backlog item.”(Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''PROBLEM'''</TD>
<TD>“Technical problems that occur and must be solved to implement a change.” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''SOLUTION'''</TD>
<TD>“Solutions to the problems and risks, often resulting in changes.” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''RISK'''</TD>
<TD>“Risks that affect the success of the project are continuously assessed and responses planned. Other controls are affected as a result of risk assessment.” (Schwaber, K.)</TD>
</TR>
<TR>
<TD>'''ISSUE'''</TD>
<TD>“Overall project and project issues that are not defined in terms of packets, changes and problems.” (Schwaber, K.)</TD>
</TR>
</TABLE>
 
== Artifacts ==
==Interaction between Phases and controls==
{{more citations needed section|date=March 2013}}
To explain how the activities interact with or reproduce these controls the following image is given. For explanation of the mentioned activities and controls see table 1 and 2.
[[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>
[[Image:Scrum development Process data diagram.GIF]]
 
=== Product backlog ===
==References==
{{main|Product backlog}}
*[http://members.cox.net/risingl1/articles/IEEEScrum.pdf (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams] Retrieved August 15, 2006
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>
*[http://jeffsutherland.com/oopsla/schwapub.pdf (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process] Retrieved August 15, 2006
*[http://jeffsutherland.com/Scrum/FirstScrum2004.pdf (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum] Retrieved August 15, 2006
*[http://www.controlchaos.com/ (URL) Control Chaos]
 
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" />
==See also==
Some other Agile methods that have similarities with Scrum are:
*[[DSDM|Dynamic System Development Method]]
*[[Feature Driven Development]]
*[[Extreme programming]] ('''XP''') - often driven by scrum
 
==External=Sprint linksbacklog===
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>
 
=== Increment ===
* [http://www.implementingscrum.com/ Implementing Scrum]
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.
* [http://www.scrumalliance.org/ Scrum Alliance]
* [http://video.google.co.uk/videoplay?docid=-7230144396191025011 Scrum et al] - Google Techtalk with Ken Schwaber
* [http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf Scrum and XP from the Trenches]
*[http://www.softdevarticles.com/modules/weblinks/viewcat.php?cid=46 Scrum articles directory]
*[http://www.agilealliance.org/article/articles_by_category/17 Agile Alliance's Scrum library]
*[http://www.controlchaos.com Control Chaos]
 
=== Other artifacts ===
[[Category:Agile software development]]
==== 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.
[[sh:Scrum]]
 
==== Release 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.
 
==== Velocity ====
{{main|Velocity (software development)}}
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.
 
== Limitations ==
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>
 
== 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|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>
 
=== Scrumban ===
{{Main|Scrumban}}
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>
 
=== 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>{{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>
 
===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]].<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>
 
== Criticism ==
{{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.
 
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>
 
== See also ==
* [[Agile software development]]
** [[Agile testing]]
* [[Agile learning]]
* [[Disciplined agile delivery]]
* [[Comparison of scrum software]]
* [[High-performance teams]]
* [[Lean software development]]
* [[Project management]]
* [[Unified process]]
 
== Citations ==
{{reflist}}
 
== General and cited references ==
{{Refbegin}}
* {{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}}
* {{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 }}
* {{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 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}}
* {{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 }}
* Verheyen, Gunther (2013). ''Scrum – A Pocket Guide (A Smart Travel Companion)''. {{ISBN|978-90-8753-720-3}}.
{{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]]
Retrieved from "https://en.wikipedia.org/wiki/Scrum_(software_development)"