Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is, when the framework is used properly. Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.
When is Scrum Applicable?
Scrum is best suited in the case where a cross-functional team is working in a product development setting where there is a nontrivial amount of work that lends itself to being split into more than one 2 – 4 week iteration.
Scrum Values
Teams following scrum are expected to learn and explore the following values:
- Commitment
- Team members personally commit to achieving team goals
- Courage
- Team members do the right thing and work on tough problems.
- Focus
- Concentrate on the work identified for the sprint and the goals of the team.
- Openness
- Team members and stakeholders are open about all the work and the challenges the team encounters.
- Respect
- Team members respect each other to be capable and independent.
Principles of Scrum
The following principles underpin the empirical nature of scrum:
Transparency
The team must work in an environment where everyone is aware of what issues other team members are running into. Teams surface issues within the organization, often ones that have been there for a long time, that get in the way of the team’s success.
Inspection
Frequent inspection points are built into the framework to allow the team an opportunity to reflect on how the process is working. These inspection points include the Daily Scrum meeting and the Sprint Review Meeting.
Adaptation
The team constantly investigates how things are going and revises those items that do not seem to make sense.
Scrum Practices
Events
Sprint
The Sprint is a timebox of one month or less during which the team produces a potentially shippable product Increment. Typical characteristics of Sprints:
- Maintain a consistent duration throughout a development effort
- A new Sprint immediately follows the conclusion of the previous Sprint
- The start date and end date of Sprint are fixed
Sprint Planning
A team starts out a Sprint with a discussion to determine which items from the product backlog they will work on during the Sprint. The end result of Sprint Planning is the Sprint Backlog.
Sprint Planning typically occurs in two parts. In the first part, the product owner and the rest of the team agree on which product backlog items will be included in the Sprint.
In the Second Part of Sprint Planning, the team determines how they will successfully deliver the identified product backlog items as part of the potentially shippable product increment. The team may identify specific tasks necessary to make that happen if that is one of their practices. The product backlog items identified for delivery and tasks if applicable make up the Sprint Backlog.
Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint.
Daily Scrum
The Daily Scrum is a short (usually limited to 15 minutes) discussion where the team coordinates their activities for the following day. The Daily Scrum is not intended to be a status reporting meeting or a problem-solving discussion.
Sprint Review
At the end of the Sprint, the entire team (including the product owner) reviews the results of the sprint with stakeholders of the product. The purpose of this discussion is to discuss, demonstrate, and potentially give the stakeholders a chance to use, the increment in order to get feedback. The Sprint Review is not intended to provide a status report. Feedback from the sprint review gets placed into the Product Backlog for future consideration.
Sprint Retrospective
At the end of the Sprint following the sprint review, the team (including the product owner) should reflect upon how things went during the previous sprint and identify adjustments they could make going forward. The result of this retrospective is at least one action item included on the following Sprint’s Sprint Backlog.
Artifacts
Product Backlog
The product backlog is an ordered list of all the possible changes that could be made to the product. Items on the product backlog are options, not commitments in that just because they exist on the Product Backlog does not guarantee they will be delivered. The Product Owner maintains the product backlog on an ongoing basis including its content, availability, and ordering.
Sprint Backlog
The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint Goal.
Increment
The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by the end of the Sprint. The Product Owner may decide to release the increment or build upon it in future Sprints.
Definition of Done
The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.
Roles
The Product Owner
The product owner is a role team responsible for managing the product backlog in order to achieve the desired outcome that the team seeks to accomplish. The product owner role exists in Scrum to address challenges that product development teams had with multiple, conflicting directions or no direction at all with respect to what to build.
The Scrum Master
The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use. The name was initially intended to indicate someone who is an expert at Scrum and can therefore coach others. The role does not generally have any actual authority. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.
The Development Team
The development team consists of the people who deliver the product increment inside a Sprint. The main responsibility of the development team is to deliver the increment that delivers value to every Sprint. How the work is divided up to do that is left up to the team to determine based on the conditions at that time.
Lifecycle
Scrum is a framework that allows development teams the flexibility to respond to changing situations. This framework has sufficient control points in place to ensure the team does not stray from the desired outcome, and that issues can be identified and resolved and process adjustments made while the effort is still underway.
The Scrum Lifecycle starts with a prioritized backlog but does not provide any guidance as to how that backlog is developed or prioritized.
The Scrum Lifecycle consists of a series of Sprints, where the end result is a potentially shippable product increment. Inside these sprints, all of the activities necessary for the development of the product occur on a small subset of the overall product. Below is a description of the key steps in the Scrum Lifecycle:
- Establish the Product Backlog.
- The product owner and development team conduct Sprint Planning. Determine the scope of the Sprint in the first part of Sprint Planning and the plan for delivering that scope in the second half of Sprint Planning.
- As the Sprint progresses, the development team performs the work necessary to deliver the selected product backlog items.
- On a daily basis, the development team coordinates their work in a Daily Scrum.
- At the end of the Sprint, the development team delivers the Product Backlog Items selected during Sprint Planning. The development team holds a Sprint Review to show the customer the increment and get feedback. The development team and product owner also reflect on how the Sprint has proceeded so far and adapted their processes accordingly during a retrospective.
- The Team repeats steps 2–5 until the desired outcome of the product has been met.
Origins
1986: Takeuchi and Nonaka publish their article ”The New New Product Development Game” in Harvard Business Review. The article describes a rugby approach where “the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.” This article is often cited as the inspiration for the Scrum framework.
1993: Jeff Sutherland invents Scrum as a process at Easel Corporation
1995: Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference
Primary Contributions
Scrum’s primary contribution to the software development world is a simple, but effective approach to managing the work of a small collaborative team involved in product development. It provides a framework and set of simple rules that allow an appropriate amount of planning, control over the work, risk identification and mitigation, and issue identification and resolution.
Further Reading
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
Agile Project Management with Scrum by Ken Schwaber
