Scrum is one of the agile methodologies designed to guide teams in the iterative and incremental delivery of a product. Often referred to as “an agile project management framework,” its focus is on the use of an empirical process that allows teams to respond rapidly, efficiently, and effectively to change. Traditional project management methods fix requirements in an effort to control time and cost; Scrum on the other hand, fixes time and cost in an effort to control requirements. This is done using time boxes, collaborative ceremonies, a prioritized product backlog, and frequent feedback cycles. The involvement of the business throughout the project is critical as Scrum relies heavily on the collaboration between the team and the customer or customer representative to create the right product in a lean fashion. This paper provides an overview of Scrum and its use in project management.
We should first be clear on what Scrum is not. There is a common misconception that Agile is Scrum. While Scrum is indeed agile, it is not the sole method of implementing agile principles. Scrum is simply one of many agile approaches to product development. Other methods include Extreme Programming (XP), Crystal, Feature Driven Development, DSDM Atern, and so on. All of these methods adhere to the Agile Manifesto and its associated principles. A helpful metaphor would be to think of Agile as being ice cream, while Scrum, XP, Crystal, etc., are all simply different flavors, like chocolate, strawberry, vanilla. They are all agile, they are all good, and many can be used in combination.
Simply put, Scrum is an agile method of iterative and incremental product delivery that uses frequent feedback and collaborative decision making.
Scrum is based on a 1986 paper written by Hirotaka Takeuchi and Ikujiro Nonaka for the Harvard Business Review titled “The New New Product Development Game.” In this paper, the authors used the sport of rugby as a metaphor to describe the benefits of self-organizing teams in innovative product development and delivery. Jeff Sutherland, Ken Schwaber, and Mike Beedle took the ideas from this paper, including the metaphor, and applied it to their field of software development. They called their new method Scrum, after the rugby term that describes how teams form a circle and go for the ball to get it back into play again. They first applied this method at Easel Corporation in 1993. Schwaber and Beedle wrote about their experiences in their book Agile Software Development with Scrum in 2002, followed by Schwaber's book Agile Project Management with Scrum in 2004, which included the work Schwaber had done with Primavera.
Schwaber refers to Scrum as a framework and not a methodology. This is primarily due to the connotations around the word methodology, which many infer as prescriptive in nature. By contrast, Scrum simply provides a structure for delivery, but does not tell you how to do specific practices, leaving that to the team to determine. Exhibit 1 shows the basic Scrum framework.
Exhibit 1. The Original Scrum Framework
The project begins with a clear vision provided by the business, and a set of product features in order of importance. These features are part of the product backlog, which is maintained by the customer or customer representative referred to as the Product Owner. A time box commonly referred to as an iteration or sprint, is the set amount of time that the team has to complete the features selected. Sprints are generally from one to four weeks in length, and that length is maintained throughout the life of the project so as to establish a cadence. The team selects items from the product backlog that it believes can be completed in the sprint, and creates a sprint backlog consisting of the features and tasks as part of the sprint-planning meeting.
Once the team has committed to a sprint backlog, the task work begins. During this time in the sprint, the team is protected from interruptions and allowed to focus on meeting the sprint goal. No changes to the sprint backlog are allowed; however, the product backlog can be changed in preparation for the next sprint.
During the sprint, the team checks in daily with each other in the form of a 15-minute meeting known as a scrum. The team stands in a circle and each member states what they did yesterday, what they plan to do today, and what is getting in their way.
At the end of the sprint, the team demos the work they have completed to the stakeholders and gathers feedback that will affect what they work on in the next sprint. They also hold a retrospective to learn how to improve. This meeting is critical, as its focus is on the three pillars of Scrum: transparency, inspection, and adaptation.
There are only three roles in Scrum: the ScrumMaster, the Product Owner, and the Team.
The ScrumMaster is the keeper of the process, the advocate for the team, and the protector of the team. They remove obstacles, facilitate team communication, mediate discussions within the team and negotiate with those external to the team. Above all, they exist in service to the team.
The Product Owner represents the voice of the customer and has the authority to make decisions about the product. This person owns the product backlog and is responsible for communicating the vision to the team, and defining and prioritizing backlog items. The Product Owner works with the team on a daily basis to answer questions and provide product guidance.
The Team consists of seven plus or minus two people who are jointly responsible for the delivery of the product. They own the estimates, make task commitments, and report daily status to each other in the daily scrum. They are self-organizing, meaning that structure appears without explicit intervention from the outside. In other words, the team owns how it chooses to build product features—the team owns the “how,” while the Product Owner owns the “what.”