TheScrumDevelopmentProcess.doc

The Scrum Development Process 1
The Daily Scrum 2
Product Backlog 3
The Product Owner 4
Release Burndown 5
ScrumMaster 6
The Scrum Team 6
Sprint Backlog 7
Sprint Planning Meeting 8
Sprint Review Meeting 9
Task Boards 9
Scrum Illustration 13
The Scrum Development Process
Scrum is an agile process for developing software. With Scrum, projects progress via a series of month-long iterations called sprints.
Scrum is ideally suited for projects with rapidly changing or highly emergent requirements. The work to be done on a Scrum project is listed in the Product Backlog, which is a list of all desired changes to the product. At the start of each sprint a Sprint Planning Meeting is held during which the Product Owner prioritizes the Product Backlog and the Scrum Team selects the tasks they can complete during the coming Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog.
Each day during the sprint conducts a brief daily meeting called the Daily Scrum, which helps the team stay on track.
At the end of each sprint the team demonstrates the completed functionality at a Sprint Review Meeting.
Graphically, Scrum looks something like this:

The following Scrum topics are available:
· Daily scrum
· Product backlog
· Product owner
· Release burndown
· ScrumMaster
· Scrum team
· Sprint backlog
· Sprint planning meeting
· Sprint review meeting
· Using a task board
· Scrum illustrations and wallpapers
The Daily Scrum 
On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally the daily scrums are held in the morning as they help set the context for the coming day's work.
There is an old joke in which a chicken and a pig are talking and the chicken says, "Let's start a restaurant." The pig replies, "Good idea, but what should we call it?" "How about 'Ham and Eggs'" says the chicken. "No thanks," says the pig, "I'd be committed, you'd only be involved." The joke is meant to point out the difference between those who are committed on a project and those who are only involved. Scrum affords special status to those who are committed and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum.
All team members are required to attend the daily scrum. Anyone else (for example, a departmental VP, a salesperson, or a developer from another project) is allowed to attend but is there only to listen. This makes the daily scrums an excellent way for a Scrum team to disseminate status information--if you're interested in hearing where things are at, attend that day's meeting.
The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains. The daily scrum is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. If a programmer stands up and says "Today I will finish the data storage module" everyone knows that in tomorrow's meeting he will say whether or not he did finish. This has the wonderful effect of helping a team realize the significance of these commitments and that their commitments are to each other, not to some far-off customer or salesman.
Any impediments that are raised become the ScrumMaster's responsibility to resolve as quickly as possible. Typical impediments are:
· My ____ broke and I need a new one today.
· I still haven't got the software I ordered a month ago.
· I need help debugging a problem with ______.
· I'm struggling to learn ______ and would like to pair with someone on it.
· I can't get the vendor's tech support group to call me back.
· Our new contractor can't start because no one is here to sign her contract.
· I can't get the ____ group to give me any time and I need to meet with them.
· The department VP has asked me to work on something else "for a day or two."
In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues) he still takes responsibility for making sure someone on the team does quickly resolve the issue.
Product Backlog
The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requirements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
During the Sprint Planning Meeting the Product Owner prioritizes the items in the Product Backlog and describes them to the team. The team then determines which items they can complete during the coming Sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five.
Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). A very interesting prospect is expressing Scrum backlog items in the form of Extreme Programming's User Stories.
An example Product Backlog from a real project appears as the following:

This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates have been developed by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints.
The Product Owner
The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.
The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog.
In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.
Release Burndown
On a Scrum project, the team tracks its progress against a release plan by updating a release burndown chart at the end of each sprint. The horizontal axis of the release burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers--story points, ideal days, team days, and so on. My preference is for story points, for all of the reasons described in the Agile Estimating and Planning book.

On this burndown chart, the team started a project that was planned to be eleven two-week sprints. They began with 200 story points of work. The first sprint went well and from the chart you can infer that they had around 180 story points of work remaining after the first sprint. During the second sprint, however, the estimated work remaining actually burned up. This could have been because work was added to the project or because the team changed some estimates of the remaining work. From there the project continued well. Progress slowed during sprint 7 but then quickly resumed.
This type of release burndown chart works very well in many situations and in many teams. However, on projects with lots of changing requirements you may want to look at an alternative release burndown chart.
ScrumMaster
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not overcommit themselves to what they can achieve during a sprint.
The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings.
The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.
The Scrum Team
Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."
A typical Scrum team is 6-10 people but Jeff Sutherland has scaled Scrum up to over 500 people and I have used it with over 150.
The primary way of scaling Scrum to work with large teams is to coordinate a "Scrum of Scrums." With this approach each Scrum team proceeds as normal but each team also contributes one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.
The illustration below shows how a Scrum of Scrums approach allows Scrum to scale up (in this case to 243 people). Each cell represents one person on a Scrum team. The bottom of this illustration shows teams with nine developers on them. One person from each team (the differently colored cell) also participates in a Scrum of Scrum to coordinate work above that team. Then from those nine-person teams another person is selected (this time shown with diagonal lines) to participate in what might be called a Scrum of Scrums of Scrums.

Sprint Backlog
The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.
The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of the Sprint Backlog in Excel looks like this:

During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done. The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burndown chart like this one:

The team does its best to pull the right amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint planning meeting. In this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 600 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully.
Sprint Planning Meeting
The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives.
During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog.
The product owner doesn't have to describe every item being tracked on the product backlog. Depending on the size of the backlog and the speed of the team it may be sufficient to describe only the high priority items, saving the discussion of lower priority items for the next sprint planning meeting. Typically, the Scrum team will provide guidance when they start to get further into the backlog list than they know could be done in the next sprint.
Collectively, the Scrum team and the product owner define a sprint goal, which is a short description of what the sprint will attempt to achieve. The success of the sprint will later be assessed during the Sprint Review Meeting against the sprint goal, rather than against each specific item selected from the product backlog.
After the sprint planning meeting, the Scrum team meets separately to discuss what they heard and decide how much they can commit to during the coming sprint. In some cases there will be negotiation with the product owner but it will always be up to the team to determine how much they can commit to completing.
Sprint Review Meeting
At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.
Participants in the sprint review typically include the Product Owner, the Scrum team, the ScrumMaster, management, customers, and engineers from other projects.
During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting. Ideally the team has completed ea