What is Scrum
Scrum is a framework for developing products and managing work in an iterative and incremental manner.
Scrum is not a highly prescriptive framework. Instead, it provides a small set of simple rules your team can use to take an empirical approach to your work.
When your team adopts the Scrum framework, you:
establish a hypothesis of how you think something works
try it out
reflect on the experience, and
make the appropriate adjustments.
Because of this experimental nature, there are very few rules. That means your Scrum team has a great deal of flexibility to determine the appropriate practices for your situation.
Scrum history
Jeff Sutherland and Ken Schwaber initially developed the Scrum framework in the mid 1990’s.
They based the framework on their work and the ideas contained in an article published in the Harvard Business Review in 1986 by Takeuchi and Nonaka entitled “The New New Product Development Game.”
They continued to expand the framework through different methods. Jeff investigated ways to implement Scrum across entire organizations.
Ken created the Certified Scrum Master Course, the Scrum Alliance and wrote a series of books to teach others about the framework.
In 2010, Jeff and Ken created the Scrum Guide to stand as the official definition of the Scrum framework. The pair continues to maintain the Scrum Guide.
Components of the Scrum framework
In order to best understand the Scrum framework, it’s helpful to understand its main components.
Scrum is based on a foundation of principles and values.
The framework calls for a Scrum team with three defined roles.
The Scrum team uses a collection of artifacts to maintain shared understanding
A Scrum team organizes its work into a lifecycle with repeating timeboxes known as sprints.
Scrum principles and values
The Scrum framework is an iterative, incremental approach built on a foundation of empiricism and lean thinking.
Your team learns from experience and makes decisions based on what you observe.
This helps you seek to reduce waste and focus on the essential activities to deliver your desired outcome.
Principles
This foundation of empiricism incorporates three principles: transparency, inspection, and adaptation.
It’s essential that your team works in an environment of true transparency. That means that everyone on your team identifies any issues that prevent them from reaching you desired outcome.
The Scrum framework has frequent inspection points that allow your team to reflect on how your process is working.
There is no point to frequent inspections if no action occurs as a result. The Scrum framework also calls for your team to adapt it’s approach based on what you observe is and is not working.
You can use these principles as a guide when you revise your process. At some point you may stop doing some of the practices described below.
Values
In addition to the three principles, your team needs to live five values . Those five values are commitment, focus, openness, respect, and courage.
Your team commits to support each other in the quest to deliver your desired outcome. You’ll usually express the steps toward the outcome as sprint goals.
Your team focuses on the outputs planned for a sprint to make the best progress toward the desired outcomes.
Your team and your stakeholders are open about the outcome to deliver, the outputs needed to get there, and the challenges that stand in your way.
The members of your team respect each other as independent, capable people.
Your team exhibits the courage to do the right thing and do what needs to be done to deliver the targeted outcome.
These values provide guidance on how a Scrum team approaches their work. It also guides how a Scrum team behaves toward each other and people outside the team.
When your Scrum team embodies those values and principles you’ll find that you’re working in an environment of high trust.
The Scrum team
The Scrum team includes a group of people with the skills and expertise needed to achieve their desired outcomes. Because it is not too prescriptive, the Scrum framework does not include much role definition. It includes three roles:
Product owner
Scrum master
Developers
The product owner
The product owner decides what to include in the Product.
The main ways to do this included in the Scrum framework is stocking and prioritizing the product backlog.
As a result, the product owner decides what features are or are not included in the product.
The role title is intentionally singular in nature.
The creators of the framework felt that it was essential for there to be one person ultimately making decisions about what features should or should not be included in the product and what those features should look like.
In practice, most product development efforts have multiple customers, users, and stakeholders.
There is generally one decision maker, but many people may have input into those decisions.
So while there may be one product owner for a team, they can’t work in a vacuum.
As you might expect, there has been a considerable amount of confusion about the relationship between product owners and product managers.
Product owner is a role that specifies what a product person does as part of the Scrum framework while product manager is a job.
The responsibilities of a product owner are the subset of responsibilities of a product manager related to working with developers.
The Scrum master
If you’re the Scrum master for your team, you act as the guardian of the process. Your purpose is to:
Set up your team’s environment to allow your team to succeed
Remove obstacles that get in the way of your team
Coach and mentor your team on working together and on the particular processes they choose to adopt.
It is worth noting that a Scrum team manages their own day-to-day work.
The team decides who does what tasks, and they track the status of that work throughout the process.
This leaves the Scrum master to focus on finding ways to help your team become more effective.
Developers
Scrum does not dictate specific development practices so there is no need for the framework to include a lot of specialized roles. “Developers” refers to all the people on the team who have the skills to create an increment of the product each sprint.
In most teams “developers” includes everyone who is not explicitly the Scrum master or product owner.
That group could include engineers, product designers, testers, analysts, data scientists and whatever skill set your team needs to deliver a viable product.
The main responsibility of the team is to develop functionality that delivers value every sprint.
The Scrum determines how to develop functionality and how to divide up their work.
The general set of responsibilities for developers include:
Planning the sprint via the sprint backlog
Ensuring quality via creating and adhering to a definition of done
Adapting their plan daily in order to continue progress toward the sprint goal
Exhibit self discipline and support each other to reach their intended outcome
Scrum artifacts
The Scrum framework identifies only three specific artifacts:
Product backlog
Sprint backlog
Increment
Product backlog
The product backlog is a prioritized list of product backlog items. Those items represent the changes to a product that accomplish a specific outcome.
Those changes could be new features, bug fixes, infrastructure changes, or other activities.
Product backlog items are options rather than commitments. Just because an item is on a backlog, it doesn’t guarantee that the team will work on it. Conversely, a Scrum team does not work on something that is not on the product backlog.
Product backlog items can take a variety of formats, but the user story is the most common form. It’s up to the Scrum team to decide how they want to represent product backlog items.
As long as the format explains what the item accomplishes (not necessarily how it will be accomplished).
In order to keep a product backlog manageable, it’s best to keep product backlog items to a minimum. One way you can keep the number of product backlog items to a manageable level is to keep your product roadmap in sync with your product backlog.
Only put items in the product backlog for those initiatives that are in the most current space on your roadmap.
You also want to keep most of them at a fairly broad level unless your team is close to including the product backlog item into a sprint.
Those items should be small enough to complete in a sprint and contain enough information that the team can start development work.
One way to have clarity on what constitutes what enough information looks like, the Scrum team can establish a definition of ready.
The definition of ready is an agreement on the set of conditions that need to be true in order to start development work on it.
One of the main responsibilities of the product owner role - and hence for a product manager working with a Scrum team - is managing the product backlog.
The activities involved in managing the product backlog include:
Prioritizing product backlog items
Deciding which product backlog items should be removed from the product backlog
Facilitating product backlog refinement.
It’s worth noting that anyone on the Scrum team can add items to the product backlog, but it falls to the person filling the product owner role to decide whether those items stay on the product backlog.
You’ll have to decide with your team if people can just add product backlog items whenever they like, or if you’d rather have a team discussion before anything gets included in the product backlog.
The most effective way to prioritize the product backlog items is by strict rank order. This means that the sequence of product backlog items will change on a regular basis as the Scrum team gains a better understanding of the outcome and the identified solution.
Sprint backlog
The sprint backlog is the subset of product backlog items that a team plans to complete in a sprint.
The team often selects these items based on what they need to deliver in order to accomplish the sprint goal.
Many teams also identify the tasks needed to complete the select backlog items. The combination of the backlog items and associated tasks form the final sprint backlog.
The Scrum team creates the sprint backlog during sprint planning for a particular sprint.
The product owner’s role provides guidance on what the sprint Goal should be in light of the overall outcome and makes sure the product backlog items to be considered are in priority order.
Increment
An increment is the portion of the product created during a sprint.
A sprint may result in one or several increments, and an increment can be delivered to production prior to the end of the sprint as long as it provides value and is usable.
A product owner may be involved in confirming that the increment is valuable and usable, especially if that is part of the Scrum team’s definition of done.
Scrum lifecycle
The true value of the Scrum framework is in its simple yet elegant approach to organizing the work of a Scrum team.
An underlying idea with scrum is development activities have far too many variables to effectively predict what will happen from one week to the next.
It’s better for a Scrum team to have a straightforward framework in place that gives them the flexibility they need to respond to changing situations.
This framework should have enough control points in place to ensure the team does not stray from the purpose of the effort.
The framework should also provide mechanisms for the team to identify and resolve issues and adjust their process while they're in the midst of working on their product.
Addressing issues as they arise helps the team be more effective in the long run.
Below is a description of the key activities in the Scrum lifecycle:
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
The sprint
Sprints form the regular cadence of the Scrum framework. They are fixed time periods, usually 1 - 4 weeks in length, where the Scrum team delivers one or more increments in order to meet the sprint goal.
Each developer starts the sprint by selecting a specific task from the sprint backlog and commits to completing that task. Generally each develop selects one item at a time and works on that until it is complete, at which point they select another task and work that task through to completion.
Since the developers themselves are managing the work that is getting done, it's helpful for the Scrum team to establish some guidelines to govern this work. These guidelines vary depending on the nature of the team. Some common guidelines include:
Team members help each other select tasks appropriate to their skill level
How the team tracks progress in a sprint and across sprints,
The definition of done is for backlog items
How to decide which tasks to focus on
Since each increment produced in a sprint should be valuable and usable, most Scrum teams find it works best to focus on the tasks for one backlog item at a time. That approach helps to ensure that the team does not reach the end of a sprint with a lot of work done but no completed product backlog items.
It’s important to remember that the end date of the sprint is fixed. If the Scrum team runs into difficulties, they don’t push the end date out. Rather they decrease the number of backlog items they deliver in that sprint.
During a sprint the product owner is available to answer questions that the developers have about the backlog items in progress. The product owner is also performing discovery on future backlog items and running backlog refinement sessions.
If a team is using dual track agile, the product owner is often joined by a product designer and tech lead in those discovery efforts.
Sprint planning
The Scrum team starts a sprint with sprint planning. The input to sprint planning is a prioritized product backlog, and the end result is a sprint backlog.
In the first half of sprint planning, the Scrum team agrees on what they plan to deliver during the sprint. That agreement is usually expressed as a sprint goal. The Scrum team then determines the specific product backlog items needed to reach the spring goal.
One approach that works particularly well in selecting the Product Backlog items is commitment-based planning, as described by Mike Cohn in his book Agile Planning and Estimating.
Commitment-based planning works in this fashion:
The product owner selects the highest priority item from the product backlog.
They discuss it with the developers to make sure there is enough understanding about the item to make a decision about whether the Scrum team would be able to deliver that item in the sprint.
The developers then determine whether they can commit to completing that item in the sprint (i.e. meet the definition of done).
If the developers say they can deliver that item, the product owner then selects the next highest product backlog Item, and the process repeats.
This process continues until the developers indicate that they cannot commit to delivering any more product backlog items in the upcoming sprint. At that point, the scope of the sprint is set.
In the second half of sprint planning, the developers take the product backlog Items and identify the tasks necessary to successfully deliver them in an increment. This conversation is part design discussion and part planning discussion.
The selected backlog items and the identified tasks form the sprint backlog.
Once the scope of the sprint has been established in terms of backlog items, no more backlog items can be added to the list. This protects the team from scope changes within that sprint.
That is not to say, however, that the tasks on a sprint backlog can’t change. But any changes should be made by the team based on information uncovered during the sprint.
Daily Scrum
To provide a mechanism for coordination and progress monitoring, the Scrum framework introduced the concept of the daily Scrum. The daily scrum should last no longer than fifteen minutes and provides the Scrum team an opportunity to coordinate their activities for the day and raise any obstacles that need to be addressed.
The meeting is intended for coordinating efforts, not problem solving, so if problems are identified those discussions are held after the standup.
The product owner is included as part of the daily Scrum and is usually there to identify obstacles that they can help clear or determine if there are any questions they need to answer for the developers.
Sprint review
At the end of the sprint, the Scrum team holds a sprint review with stakeholders of the product. The purpose of the sprint review is to discuss and review the increments that the team produced during the course of the sprint and identify potential revisions to the product backlog for future sprints.
Your Scrum team shouldn’t feel compelled to put a great deal of effort into preparing for a sprint review. Creating the increments should be the main preparation. During the review itself the Scrum team should briefly go over the sprint goal and sprint backlog and then demonstrate the increments. Even better if the stakeholders themselves can try out those increments.
The product owner’s role during the sprint review may vary. In some instances, the product owner may facilitate the sprint review, especially if you’ve been involved with the team throughout the sprint.
In other cases if you aren’t as involved with the team during the course of the sprint, you may use the sprint review to get up to speed on what the team has done. If you find yourself in this situation too much, you may want to determine if you should be more involved with your team on an ongoing basis.
The output from the sprint review may be changes to your product backlog based on the feedback you receive during the review.
Sprint retrospective
Following the sprint review, the Scrum team holds a short retrospective to reflect upon how things went during the previous sprint and identify adjustments the Scrum team could make going forward.
This event includes the entire Scrum team (product owner, Scrum master, and developers) and provides the team a regular check point to reflect on their approach and make the appropriate modifications.
Just because you have a retrospective at the end of a sprint doesn’t mean you should leave it until then to work through challenges with your approach or amongst your team. If someone on your Scrum team identifies an issue during the course of the sprint, there’s no reason you can’t discuss it right then rather than waiting until the sprint retrospective.
The product owner’s role during a sprint retrospective is to be an active participant. In some cases you may find that many of the items you address is how you work with the rest of the Scrum team.
What Scrum means for product managers
Hopefully, you’ve seen by now that the Scrum framework basically covers how a Scrum team manages it’s work. While it does have a role for a product person-the product, owner-the only aspect of product management that role covers is how you interact with developers.
There is much more to product management than managing a backlog and creating backlog items. If your team is using the Scrum framework (or some variation of it) it’s helpful to understand the framework, but to be an effective product manager, you need to do much more than effective product ownership.
Kent McDonald
Read also
Prioritize with confidence
