An Introduction to Scrum

14 November 2013

Robert Weidner
Marshfield Clinic

Scrum is an Agile process, focused on iterative and incremental development.

Projects have increased in complexity to the point where it no longer makes sense to define all requirements up front. Often, by the time the project is delivered, the requirements have changed. Scrum was designed to solve this dilemma by introducing continual feedback and flexibility into the developmental process. By dedicating resources, collapsing feedback loops, timeboxing activities, and adapting to design changes, Scrum teams deliver the greatest ROI back to the business.

Scrum emphasizes the following ideals:
  • Flexibility
  • Continual feedback
  • Collaboration
  • Self-organizing behavior
  • Emergent design
The Scrum process may seem simple, which it is; but it’s also an ideal methodology for handling complex projects. Scrum principles are cultivated through the following activities:
  • In most cases, team members are dedicated to one Scrum project at a time.
  • Development is timeboxed into sprints, which can last from 7 to 30 days each.
  • At the end of every sprint, the completed work is presented to stakeholders for feedback, acceptance, or both.
  • If feedback is needed sooner, the team will arrange collaboration with the product owner.
  • All team members work to achieve the overall goal of the sprint, regardless of specialization.
  • The product leads. . . .

Scrum roles

There are three defined roles in Scrum: the product owner, the team, and the ScrumMaster. Together, they form the Scrum team.

The product owner represents the interests of all stakeholders. His or her goal is to deliver the greatest return on investment for the business. This begins with the creation of a product backlog, which defines the goals of the project, often via user stories. The product owner then prioritizes the objectives, working with the stakeholders to determine ROI, and communicates with the team to understand any technical dependencies. The product owner should be available to the team for continual feedback, goal definition, and prioritization. The team will commit to the amount of work it thinks it can get done during a single sprint, and it should communicate that to the product owner during the sprint planning meeting.

Once the work is agreed on and committed to, those work items will be moved from the product backlog onto the sprint backlog. The team then performs task decomposition and begins the sprint. The team may seek additional feedback and clarification from the product owner throughout the process. Once the sprint has been completed, the team will demonstrate the finished work to the product owner during the sprint review meeting. The product owner will determine if the work has met the "done" criteria (which should have been established during the sprint planning meeting) and whether or not the work will be accepted as complete.

Then, if the Scrum project continues, during the next sprint planning meeting the product owner will work with the team to determine which items from the product backlog will become part of the next sprint. Because items can be added to the product backlog at any time, by anyone, it remains the responsibility of the product owner to groom and prioritize the product backlog as needed. The product owner is the one who owns the product backlog, while the team owns the sprint backlog.

The team is responsible for working with the product owner to determine technical dependencies and to negotiate how much work it believes can be completed during a single sprint. Once the work has been committed to, the team is solely responsible for developing functionality to meet those goals. The team is a cross-functional group intended to exhibit self-organizing behavior. The work may include, but is not limited to, analysis, design, development, testing, communication, and documentation. During the sprint, the team should engage the product owner as necessary for feedback and clarity on development goals. No task should be considered complete until it meets the done criteria, as set forth by the product owner.

At the end of the sprint, the team should discuss, and if possible demo, all completed work to the product owner and any other stakeholders who may be interested. Then, if the Scrum project continues, the team should work with the product owner during the sprint planning meeting to determine the goals of the next sprint. The team is responsible for maintaining the sprint backlog, including task decomposition. The product owner tells the team what to work on; it is the team’s job to figure out how to get the work done.

The ScrumMaster is responsible for ensuring that the team and product owner understand and follow the Scrum process. It is the ScrumMaster's job to implement process improvements, which may occur in an incremental and iterative fashion, based on feedback received during the sprint retrospective meeting. The ScrumMaster is also responsible for removing any impediments that individual team members may encounter, and for overall team health. The ScrumMaster has no authority: The decision-making process occurs in negotiations between the product owner and the team.


Scrum relies on the following meetings to increase communication, clarify the goals of the sprint, collapse feedback loops, and structure the process:

During the sprint planning meeting, the product owner collaborates with the team to select work items for the next sprint. Items are moved from the product backlog to the sprint backlog, and the product owner will define the "done criteria." Once the team commits to the work, then the product owner vacates the meeting. The team continues, performing task decomposition and providing remaining work estimates.

The daily Scrum is a 15-minute meeting held every day throughout the course of a sprint, during which all team members answer the following three questions: 1) What have you done? 2) What will you do? 3) What impediments do you have? The meeting is intended to open lines of communication among team members and ensure that everyone is aware of the current status for work items in the current sprint. The discussion is time limited and should remain focused on the topic at hand. The team can engage in further discussion after the meeting if necessary. The daily Scrum should be attended by the team and the ScrumMaster and should not be considered optional. Remote team members should be conferenced in.

At the end of every sprint, there is a sprint review, during which the completed work is discussed and demonstrated to the product owner and any interested stakeholders. The product owner will then accept the work, so long as it meets the done criteria, and provide the team with feedback.

The sprint retrospective concludes the sprint, during which team members discuss the following three questions: 1) What worked? 2) What didn't work? 3) What will we do differently during the next sprint? Scrum emphasizes an iterative and incremental approach to development, and is -- in itself -- both iterative and incremental, seeking continual process improvements through lessons learned.


There are only a few artifacts in Scrum.

The product backlog is a prioritized feature list, specifying the goals of the sprint. It is owned and maintained by the product owner, who writes the initial backlog and then prioritizes the work items. The product backlog is often written in the form of user stories, in the following template:

As a [user], I want [feature] so that [rationale].

Items on the product backlog are then sized according to "effort," in a joint collaboration between the product owner and the team. Effort is sized using a modified Fibonacci sequence, intended to denote relative complexity, which should be viewed as a combination of work effort, financial effort, quantifiable unknowns, and any other criteria you can think of. Sizing is not an exact science and is intended only to get a feel for how large the desired undertaking may be, and to lend perspective to the product owner. This way, the product owner knows what he or she is asking of the team and can prioritize the product backlog accordingly. Sizing is frequently completed with Scrum Poker cards, which are a prop used to encourage additional conversation.

During the sprint planning meeting, the team will commit to work from the product backlog, and then those items will be moved from the product backlog over to the sprint backlog. The team owns the sprint backlog and is responsible for task decomposition. It must break the user stories into small, manageable chunks of work, or tasks, which can be completed in three days or less. The sprint backlog is the primary artifact used by the team. During the sprint, team members will pull their own tasks, place their names in the "Assigned to" field, and change the status to "In Progress." At the end of every day, or the beginning of the following day, team members should update the hours in the "Remaining Work" field, which will provide an estimate for the amount of time it will take to complete the task. If the task is finished, the team member will change the status from "In Progress" to "Done."

The sprint burn-down displays a public and transparent view of the remaining work in the sprint backlog. Therefore, it is essential the team members update the "Remaining Hours" field for their tasks on a daily basis, or else the burn-down chart will not accurately reflect the progress that has been made.

There are two other artifacts in Scrum: The release burn-down, which annotates the amount of work completed during each iteration of the sprint and showcases the amount of work left to complete all items on the product backlog, and velocity, which measures the number of story points -- what we log as effort when sizing user stories -- that have been completed through each sprint cycle.


Scrum is a process that, in practice, will increase our efficiency, our productivity, and our ability to respond to changing business requirements. In the book Succeeding with Agile: Software Development Using Scrum, Mike Cohn states, "Adopting Scrum involves incorporating new practices and valuing new principles. An organization cannot adopt the practices without the underlying principles, nor can it adopt the principles without the practices."

It's time to Scrum. Let's get to work. . . .

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (4 ratings)


Phillip Stiby, CSM, 11/14/2013 3:59:17 AM
Why does scrum alliance put articles up which fail on the first sentence.

Read the guide, Scrum is a framework! Not worth reading the rest based on that.
Robert Weidner, CSP,CSM,CSPO, 11/14/2013 9:58:27 AM
Technically, Agile is a framework, while Scrum is a process. Agile is a guiding set of principles (framework). Meanwhile, Scrum advocates a series of steps (processes) that are intended to implement those principles in practice.
Shoaib Shafquat, CSM, PMP, MBA, CSM, 11/17/2013 8:28:34 AM
I think it's a good introduction. Nice Job Robert.
Kim Poo Gan, CSM, 11/20/2013 12:42:32 AM
Good introduction.
Jessica Liu, CSP,CSM, 11/20/2013 2:15:06 AM
Scrum is a framework, while agile is a methodology.
Robert Weidner, CSP,CSM,CSPO, 11/21/2013 4:54:08 PM
Ken Schwaber consistently refers to Scrum as a process. As enjoyable as this debate in semantics is, the crux of the article is really about providing an introduction to Scrum (including key principles, roles, meetings, and artifacts), rather than what to call it. If you get too hung up on the map, you’ll never see the terrain.
Robert Weidner, CSP,CSM,CSPO, 11/25/2013 1:43:20 PM
I wanted to offer one final reference regarding the identification of Scrum as a process, as well as a framework, available in the official introduction posted by the Scrum Alliance website; at the following location:

Under the section "The Scrum Framework", it states the following:

"Scrum is a framework for building a product.
Scrum is also a team process..."

The paper above was written as an introduction to the development team, and therefore referred to specific steps the team would follow. I think it's fair to view Scrum as either a framework or a process, depending on your frame-of-reference. The use of the term framework is primarily to denote the fact that Scrum is lean and flexible. That doesn't however, mean that there aren't any prescribed processes within the framework. Just because we're "agile", that doesn't mean "anything goes". The framework is a skeleton... a set of guiding principles that provide the shape and form of Scrum. What happens within those confines is then up to the team, so long as it falls under the agile umbrella, rather than outside of it.

You must Login or Signup to comment.