Scrum is an iterative and incremental software development process that is ideally suited to projects with rapidly changing or emergent requirements. As an empirical process it uses frequent inspection, collaboration and adaptive planning to evolve functionality driven by business-value. Scrum uses self-organising teams to improve communication, cooperation and learning. Active management controls conflicting interests and requirements and detects and removes obstacles in real-time to maximise productivity.

Visibility, inspection and adaptation

Scrum makes progress via a series of iterations called Sprints. The functionality to be developed is listed in the Product Backlog, a dynamic queue of business and technical features. A Sprint begins with a Sprint Planning Meeting. The Product Owner selects the highest business-value features from the Product Backlog and the Scrum Team determines how many can be developed during the Sprint. The agreed features are then moved to the Sprint Backlog. The Scrum Team proceeds to develop the desired functionality during the Sprint, and the Scrum Master tracks their progress through Daily Scrum meetings. The Sprint delivers production-quality, demonstrable business functionality, which is demonstrated to the Product Owner (and other stakeholders) at the end of the Sprint in the Sprint Review Meeting.

Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

Product Owner: A Product Owner represents the interests of his product line to the associated Scrum Master and Scrum Team, and is responsible for managing and prioritising the Product Backlog to ensure that the functionality is developed in the order of business value. The focus of the Product Owner is return on investment (ROI).

Scrum Master: The Scrum Master is a facilitator serving the Scrum Team and ensures they abide by the values and practices of Scrum. The Scrum Master chairs a Daily Scrum meeting and is responsible for ensuring the Scrum Team is able to progress with a sustained pace by making decisions and removing impediments. The Scrum Master helps the Scrum Team plan the Sprint.

Scrum Team: A Scrum Team is self-managing, self-organising and multi-functional, and typically comprises 6 to 10 people. It is responsible for converting Product Backlog into a working increment within a Sprint. Everyone works together to complete the work they have collectively committed to complete within a Sprint. Team members and the Scrum Master, are collectively responsible for the success of each Sprint.

Product Backlog: Each product line has a dedicated Product Backlog owned by a Product Owner. It is the master list of features, functions, technologies, and enhancements that constitute the changes that will be made to the product in future releases. It is an evolving, prioritised queue of business and technical requirements that need to be developed. Anything that represents work to be done on the product is included in its Product Backlog. The Product Backlog is maintained in order of business value. Reprioritisation occurs in response to changes in the business priorities that are inevitable over time. Top priority Product Backlog drives immediate analysis and ultimately development activities.

Sprint Planning Meeting: A Sprint Planning Meeting is held at the start of each Sprint and typically lasts up to a full day. During the first half of the meeting, the Product Owner describes the highest priority items on the Product Backlog relevant to the Scrum Team who asks questions about the content, purpose and meaning of the items to help them understand the functionality to develop. The Scrum Team estimates the items they feel they can complete during the Sprint. The selected items are moved to the Sprint Backlog, and the Scrum Team define a Sprint Goal - a short description of what will be achieved during that Sprint or a summary of the Sprint Backlog. During the second half of the meeting, the Scrum Team meets separately to plan the Sprint. User stories are disaggregated into engineering tasks, which are then estimated. In exchange for the Scrum Team's commitment to complete the work selected for the Sprint, the Product Owner commits that the contents of the Sprint will not change for the duration of the Sprint. If something so significant happens that the Product Owner feels it needs to change the Sprint, then the current Sprint is aborted and a new Sprint is started with another Sprint Planning Meeting.

Sprint Backlog: The Sprint Backlog is work that the Scrum Team commits to completing in the current Sprint. The Scrum Team selects the items from the Product Backlog based on the priorities set by the Product Owner and places them onto the Sprint Backlog. The Scrum Team decides how much work they can complete in the Sprint. The Scrum Team maintains the Sprint Backlog by updating it to reflect which tasks are completed and how long they think it will take to complete those that are not yet done. The estimated work remaining in the Sprint is calculated daily and published. If work needs to be de-scoped from a Sprint it is important to still satisfy the Sprint Goal. The Product Owner decides what should be de-scoped.

Daily Scrum: During a Sprint the Scrum Team holds daily meetings in the same location and at the same time each day, ideally in the morning to set the context for the coming day's work. It provides a daily snapshot of the project and an opportunity for the Scrum Team to reconsider current assignments. It is the least time-consuming - usually 15 minutes or less and never longer than 30 minutes - and least intrusive method of gathering and sharing project information.

During the Daily Scrum each team member answers the following 3 questions:

1. What did you achieve since yesterday?
2. What are you aiming to achieve today?
3. What obstacles are in your way and what dependencies do you have?

The Scrum Master is on hand as a facilitator, making sure the meeting remains focused on the 3 questions and moves along at a brisk pace. The Product Owner is present as a stakeholder, interested in the progress of the project and the impediments it faces. By focusing on what each team member accomplished yesterday and will accomplish today the Scrum Team gains an understanding of what work has been done and what work remains. The Daily Scrum is not a status update meeting where information is collected about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. The Daily Scrum should not digress into designing parts of the system or resolving issues that were raised. Such items are noted during the meeting and are resolved offline.

Sprint Review Meeting: The Scrum Team demonstrate the functionality developed during the Sprint to the Product Owner and possibly other stakeholders, and an assessment is made against the Sprint Goal defined during the Sprint Planning Meeting. The review is informal, provides a natural conclusion to a Sprint and should not be a distraction for the Scrum Team.

Sprint Retrospective Meeting: The Scrum Master encourages the Scrum Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.

Scaling Scrum

The primary way of scaling Scrum to work with large teams is to coordinate a "Scrum of Scrums". Each Scrum Team also contributes one person, typically the Scrum Master, to the Scrum of Scrums meeting to coordinate the work of multiple Scrum Teams. These meetings are analogous to the Daily Scrum but happen weekly rather than daily.

XP@Scrum

Scrum is an effective project management wrapper for eXtreme Programming development practices, which enables agile projects to become scalable and developed by distributed teams of developers.