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.
Scrum is best suited in the case where a cross functional team is working in a product development setting where there is a non trivial amount of work that lends itself to being split into more than one 2 – 4 week iteration.
Teams following scrum are expected to learn and explore the following values:
Team members personally commit to achieving team goals
Team members do the right thing and work on tough problems.
Concentrate on the work identified for the sprint and the goals of the team.
Team members and stakeholders are open about all the work and the challenges the team encounters.
Team members respect each other to be capable and independent.
The following principles underpin the empirical nature of scrum:
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.
Frequent inspection points 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.
The team constantly investigates how things are going and revises those items that do not seem to make sense.
- Maintain a consistent duration throughout a development effort
- A new Sprint immediately follows the conclusion of the previous Sprint
- Start date and end date of Sprint are fixed
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, makes 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.
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.
At the end of the Sprint, the entire team (including 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.
At the end of the Sprint following the sprint review the team (including 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.
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.
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.
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.
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 direction, 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 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.
Scrum is a framework that allows development teams 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 of 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, development team perform the work necessary to deliver the selected product backlog items.
- On a daily basis, the development team coordinate 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 adapting their processes accordingly during a retrospective.
- The Team repeats steps 2–5 until the desired outcome of the product have been met.
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
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, and risk identification and mitigation and issue identification and resolution.
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
Agile Project Management with Scrum by Ken Schwaber