Scrum
A common misconception is that Scrum is an acronym: SCRUM; not so. Scrum is named after the Scrum in Rugby, which is a mechanism to restart the game after an accidental infraction - such as the ball going out of bounds. It's the general idea of a team huddling together to move the ball toward the goal.

Scrum is a project management framework for managing Agile projects. Its primary goal is to deliver software that, after each and every iteration, provides the highest business value. Scrum is based on a 30-day iteration called a "Sprint." Technically Sprints can be either two or four weeks, but the generally accepted default is usually four weeks.

A fundamental Scrum principal is that project teams should be self organizing. This means that team members don't follow a prescriptive plan or set of tasks, but organize themselves initially based on the goals for the Sprint, and subsequently on a daily basis through daily scrum meetings. Recommended team size is from four to nine members.

Every day at the same time, the project team meets to discuss the project. Members are expected to stand during the entire meeting to encourage short meetings. Meetings are targeted to complete in 10 to 15 minutes. Each member in turn answers three questions:

1. What did I do since the last Scrum meeting?
2. What do I plan on doing between now and the next Scrum meeting?
3. Do I have any roadblocks?

This report is not a status meeting. In other words, team members do not report on what percent a task is done. They report on what work they did, why it was being done, and whether it has been completed or not. When something is encountered that is impeding progress, it is considered a roadblock. As roadblocks are reported, the team decides how to handle them, including escalating them immediately to the appropriate channel.

When multiple teams are involved in a project, a hierarchy of daily scrum meetings may occur, sometimes referred to as a Scrum of Scrums. An example would be where three teams are involved in working on three separate but related Sprints. Each team would hold their daily Scrum, and then one member from each team would convene together for an additional Scrum to make sure team coordination occurs. Information from this additional Scrum is fed back into the separate team Scrums the following day.

Scrum also defines only a small numbers of roles on the team:

Product Owner—The Product Owner is responsible for representing the customer or user of the product the team is building. Ideally this is the actual customer, but when the customer is not available for a project, this role is filled by someone representing the customer's interests; he or she is also responsible for being the liaison between the project team and the customer.

Scrum Master—Scrum originated as a way to deal with troubled or emergency projects. The person brought in to refocus the project team is called a Scrum Master. This role is primarily to facilitate, report, and focus the team on the highest priority work and to remove any roadblocks that may impede team progress. Certification training for Scrum Masters exists, supporting three different levels of practice.

Team Member—All other members of the team are considered general team members. This includes developers, architects, project managers, testers, database administrators—everyone. The team concept is important to Scrum and only the key roles of Scrum Master and Product Owner are called out.

Scrum uses the term "backlog" to refer to a list of items that are related. Three backlogs are defined by the Scrum process: product backlog, release backlog, and sprint backlog.

Figure 2. Scrum Burndown Chart. A Scrum Burndown Chart helps to provide visibility of the progress of the team and the work remaining. The straight line represents an ideal iteration where work is completed in a perfectly steady and evenly distributed manner. The more erratic line represents the work that is actually completed over time by the team.

The product backlog is a list of all the requirements to deliver the product. These are usually defined at a high level, and include estimates used to scope the Sprint Backlogs. The Release Backlog is pulled from the Product Backlog, which contains requirements. This list must be in priority order, with each entry on the list having a unique priority. Here, each requirement also includes a more granular estimate than that given in the product backlog.

At the start of each Sprint, the project team breaks down items from the Release Backlog, starting at the top (most important), and adds these into the Sprint Backlog. Once enough items have been selected to fill the Sprint, the Sprint Backlog is locked. Estimates include total time to complete each item, including but not limited to analysis, design, coding, testing, documentation, etc.

There is another item related to Backlogs that is key to Scrum. The Burndown Chart (see Figure 2) is used to indicate the number of remaining Sprint Backlog items yet to be completed in the current Sprint. A daily record is maintained showing the team's progress in achieving the goal of the Sprint.

At the end of a Sprint, the team meets with any interested stakeholders to demonstrate what work has been completed, and to evaluate priorities for the next Sprint. In addition, any outstanding roadblocks are also discussed, as well as their impact and possible solutions.

One final note is that since Scrum focuses on the project management aspects of a project and specifies no technical practices, it integrates well with other Agile methodologies. It is commonly combined with XP, but will work with other approaches as well.