Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.

Although the Scrum approach was originally suggested for managing product development projects, its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach.



Scrum is a process skeleton that 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 the business.

3. The "Team", a cross-functional group who do the actual analysis, design, implementation, testing, etc.


A sprint is the basic unit of development in Scrum. Sprints tend to last between one week and one month and are a "timeboxed" (i.e. restricted to a specific duration) effort of a constant length.

Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

During each sprint, the team creates a potentially deliverable 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 or she wants completed. The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

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.


Core Scrum roles

The core roles in Scrum teams are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project).

Product Owner

The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typicallyuser stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the Development Team, it is recommended that this role not be combined with that of ScrumMaster.


The Team is responsible for delivering the product. A Team is typically made up of 5–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). It is recommended that the Team be self-organizing and self-led, but often work with some form of project or team management.

Scrum Master

Scrum is facilitated by a ScrumMaster, also written as Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader 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 at hand. The role has also been referred to as servant-leader to reinforce these dual perspectives.

Ancillary Scrum roles

The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process—but nonetheless, must be taken into account.

Stakeholders (customers, vendors)

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.

Managers (including Project Managers)

People who will set up the environment for product development.


Daily Scrum

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

1. The meeting starts precisely on time.

2. All are welcome, but normally only the core roles speak.

3. The meeting is timeboxed to 15 minutes.

4. The meeting should happen at the same location and same time every day.

During the meeting, each team member answers three questions:

1. What have you done since yesterday ?

2. What are you planning to do today ?

3. Any impediments/stumbling blocks ?

It is the role of the ScrumMaster to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it under 15 minutes.

Scrum of scrums

Each day normally after the daily scrum.

1. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

2. A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four questions:

1. What has your team done since we last met ?

2. What will your team do before we meet again ?

3. Is anything slowing your team down or getting in their way ?

4. Are you about to put something in another team’s way ?

Sprint Planning Meeting

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

1. Select what work is to be done

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

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

4. Eight hour time limit

5. (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog

6. (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog

At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective"

Sprint Review Meeting

1. Review the work that was completed and not completed

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

3. Incomplete work cannot be demonstrated

4. Four hour time limit

Sprint Retrospective

1. All team members reflect on the past sprint

2. Make continuous process improvements

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

4. Three hour time limit

System Admin

It has survived not only five centuries, but also the leap into electronic typesetting, remaining popularised only five Power of centuries.

-Learn more

System Admin

It has survived not only five centuries, but also the leap into electronic typesetting, remaining popularised only five Power of centuries.

-Learn more

System Admin

It has survived not only five centuries, but also the leap into electronic typesetting, remaining popularised only five Power of centuries.

-Learn more

System Admin

It has survived not only five centuries, but also the leap into electronic typesetting, remaining popularised only five Power of centuries.

-Learn more