Before I begin blogging about our Scrum journey, it is probably worthwhile for me to provide an overview of what exactly Scrum is.  I'll provide a concise description here and elaborate on specific Scrum components in future posts.  Scrum is an Agile process which was originally developed by Ken Schwaber and Jeff Sutherland in the early 1990's.  Essentially Scrum is a lightweight, iterative process for managing complex projects.  Scrum emphasizes complete project visibility, self-organizing teams, and constant inspection and adaptation throughout the life of a project. 

The Players in Scrum

Scrum has 3 basic roles: the ScrumMaster, the Product Owner, and the Team.  The ScrumMaster is responsible for the Scrum implementation and is the driving force behind the Scrum process. The ScrumMaster essentially replaces the traditional project manager.  However, the ScrumMaster is not the team leader.  Instead, the ScrumMaster's primary responsibility is to remove any impediments that stand in the way of the Team reaching its goal of producing quality products.  In effect, the ScrumMaster is a servant leader. 

The Product Owner is responsible for managing and prioritizing the work that the Team needs to do, known as the Product or Project Backlog.  The Product Owner also secures funding for the development of the product. 

The Team is a cross-functional team, usually consisting of no more than 3-8 team members.  Mike Cohn of Mountain Goat Software describes the size of a Scrum the best as "The two pizza team.  If you need more than two pizzas to feed the team, it's too big!"  The Team is responsible for developing the product and for selecting items from the Project Backlog that they can turn into potentially shippable functionality at the end of every iteration.

The Mechanics of Scrum

Scrum is an iterative process.  It is based on constant cycles of inspection and adaptation.  Scrum breaks complex work into short iterations called Sprints.  A Sprint is generally 2 to 4 weeks in duration.  Before a Sprint, the Product Owner reviews the current Product Backlog of requirements (we call them User Stories) and prioritizes them to ensure that the items that are most valuable are at the top of the Project Backlog. 

Before a Sprint begins, the Product Owner, the Team, and the ScrumMaster gather at a Sprint Planning Meeting to discuss the current Product Backlog.  Our Sprint Planning meetings are generally timeboxed to 4 hours.  The Team asks all of the questions they need to in order to fully understand the Project Backlog items.  More time is spent defining the higher priority items and less time on the lower priority items. When the Team is satisfied that it understands the Backlog items, they select the highest priority items that they believe they can complete by the end of their Sprint.  The Team estimates the size and duration of the items they select to work on during the upcoming Sprint.  This selection of work that the Team collectively commits to is called the Sprint Backlog.

During the Sprint, The Team is left to work on the Sprint Backlog items with minimal interruption.  It is the responsibility of the ScrumMaster to ensure that the team is not disturbed or interrupted from their work.  During the Sprint, no work may be added to the Sprint Backlog by the Product Owner.  The goal of every Sprint is to produce a potentially shippable product increment.  This means that during each Sprint the Team must produce high quality, tested, complete functionality.  The Team's progress during a Sprint is tracked on a Sprint Burndown Chart.  The Sprint Burndown Chart indicates the amount of work remaining in the current Sprint.  The Team's overall progress on a project is tracked on a Product (or Project) Burndown Chart.  This indicates how much work is remaining on the entire project.

During the Sprint, the Team and the ScrumMaster meet on a daily basis at a meeting called the Daily Scrum (or just the Scrum).  The Scrum is a short, time-boxed meeting of no more than 15 minutes.  The Scrum is meant to synchronize the work of the Team and provide transparency into the development of the product on a daily basis.  During the Scrum, Team members answer three basic questions:

1. What did you work on yesterday?
2. What are you working on today?
3. Are there any impediments to getting your work done?

At the completion of the Sprint, the Team, the ScrumMaster and the Product Owner gather at a timeboxed meeting called the Sprint Review.  Our Sprint reviews are timeboxed to 1 hour.  At the Sprint Review, the Team demonstrates the functionality they developed during the Sprint.  No PowerPoints...no prototypes...no "This would work if..."  The Team must demonstrate working software that has been coded, tested, and documented. 

After the Sprint Review, the Team and the ScrumMaster gather without the Product Owner for a Sprint Retrospective.  The Sprint Retrospective is a timeboxed meeting (ours are timeboxed to 30 minutes for regular Sprints and 2 hours for release Sprints) at which the Team determines what has been working for them, what hasn't, and how they can make their Sprints more effective in the future. 

At the completion of the Sprint Retrospective, the whole cycle begins again with a Sprint Planning Meeting.  To visualize the entire Scrum process, check out this re-posting of Mike Cohn's graphic below (I think it's the clearest representation of the process):