Scrum derives its name from the way the ball is put back into play in a rugby match.

More than a development methodology, it defines a management framework for agile development projects. The main objective is that deliveries from each iteration should maximize value for the business for which the software is being built. It is based on the repetition of iterations every 15 to 30 days (typically four weeks), known as Sprints in the model jargon.

Development teams are self-organized. This means the plan is carried out based on an objective or set of objectives defined for the Sprint, rather than specific tasks envisaged from the outset. The team decides the most appropriate order in which to proceed in daily meetings (Scrums) lasting some 10 to 15 minutes, at which progress reports are made, difficulties are discussed and the actions to be taken during the day to meet the Sprint objectives are established.

The team is formed by 4 to 8 people with the following roles:

• Product Owner: This is the client or the user of the product the team is building. In the absence of the client, the product owner will represent the client’s interests and provide a nexus with the development team.
• Scrum Master: The scrum master performs the role of project manager. He or she is responsible for reporting the client’s priorities to the team and orienting members in the performance of the tasks established to comply with project goals. The scrum master is also responsible for removing any obstacles in the way of the team’s progress.
• Team Member: Any other member of the team. Programmers, architects, testers, data base administrators, etc.

Scrum uses the term “backlog” to define a set of related elements. Three backlogs are defined in the process:

• Product backlog: This represents all requirements that the product delivered must cover. The requirements are defined at a very high level and include development cost estimates for use in the determination of Sprint Backlogs.
• Release backlog: This is a prioritized list of the requirements contained in the product backlog. None of the priorities may be duplicated and the development cost estimate is more detailed than in the product backlog.
• Sprint backlog. At the beginning of each Sprint, the project team extracts and breaks down the elements contained in the Release Backlog, beginning with the highest priority issues. These are included in the Sprint backlog until it contains sufficient elements to perform the Sprint. At this point the Sprint backlog is blocked, and no changes to the requirements are allowed while the Sprint is in progress.

The Burndown Chart is another key element and is related with the Backlogs. It is used to control pending items in the current Sprint Backlog. The chart is updated daily to ensure that the team has feedback on the level of performance of the Sprint objectives.

At the end of the Sprint, the client and users are provided with a release detailing the progress made and an appraisal of priorities for the next Sprint. Any problems identified are also reported, requests for changes and an assessment of their impact are included, and possible solutions are discussed.

Because Scrum does not impose any practices, it combines will with other methodologies such as RUP and Agile UP that do. The model is often used in combination in smaller XP projects.

In larger projects, teams may themselves form part of larger Scrum groups or groups steered using classic project management procedures.