Quick guide to Scrum

Learn how Scrum helps teams work together and develop products faster

Try for Free

About Scrum
Scrum in six minutes

Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum framework, as defined in the SBOK® Guide, is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity.

A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints.

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholders are provided a demonstration of the Deliverables. The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders. It is important to:

  1. Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog.
  2. Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with project stakeholders showing them product increments at the end of each Sprint, enabling effective management of changes.
  3. Create Deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

Some of the key differences with respect to Value-driven Delivery in Scrum project and Traditional projects are given in the figure below.

Marketing Strategy

In Scrum projects, User Stories are ranked in order of priority which is an effective method for determining the desired User Stories for each iteration or release of the product or service. The purpose is to create a simple, single list with the goal of prioritizing features, rather than being distracted by multiple prioritization schemes.

This simple list also provides a basis for incorporating changes and identified risks when necessary. Each change or identified risk can be inserted in the list based on its priority relative to the other User Stories in the list. Typically, new changes will be included at the expense of features that have been assigned a lower priority.

Minimum Marketable Features (MMF) are also defined, so that the first release or iteration happens as early as possible, leading to increased ROI.

Click here for live discussions among project professionals on LinkedIn about Scrum vs. Traditional Project Management.

A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Usually, the results generated by projects are expected to create some form of business or service value.

Since value is a primary reason for any organization to move forward with a project, Scrum focuses on Value-driven Delivery. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle. Delivering value is ingrained in the SBOK® framework.

The concept of Value-driven Delivery in Scrum makes SBOK® framework very attractive for business stakeholders and senior management. This concept is very different when compared with traditional project management models where:

  1. Requirements are not prioritized by business value.
  2. Changing requirements after project initiation is difficult and can only be done through a time consuming change management process.
  3. Value is realized only at the end of the project when the final product or service is delivered.
  1. Create Large Project Components—This process defines how the multiple Product Owners work together and how the multiple Scrum Teams work together. Also common components and common and specialized resources are identified.
    Following figure shows all the relationship of the Create Large Project Components process to the fundamental Scrum processes in the Initiate phase.
    Create Large Project Components
  2. Conduct and Coordinate Sprints—This process is usually only relevant for large projects and addresses specific aspects that should be considered during each Sprint. If required, Scrum of Scrums Meetings are conducted to coordinate efforts between multiple Scrum Teams.
    Following figure shows all the relationship of the Conduct and Coordinate Sprints process to the fundamental Scrum processes.
    Conduct and Coordinate Sprints
  3. Prepare Large Project Release—In some large projects it may make business sense to do a special Sprint prior to a release in order to prepare for releasing the product (to be decided by the project team based on business needs). This process addresses such a preparation Sprint.
    Following figure shows the relationships of the Prepare Large Project Release process to the fundamental Scrum processes.
    Prepare Large Project Release
  1. Create Program or Portfolio Components—In this process, the Program or Portfolio Product Owner and key stakeholders identify common components and resources required for the program or portfolio. The Minimum Done Criteria are defined and all stakeholders are identified.
    Following figure shows the relationship of the Create Program or Portfolio Components process to the fundamental Scrum processes.
    Create Program or Portfolio Components
  2. Review and Update Scrum Guidance Body—In this process, the Scrum Guidance Body Recommendations are regularly reviewed by the members of the Scrum Guidance Body and are updated when and if necessary. In this process, changes in the membership of the Scrum Guidance Body are also handled.
    Following figure shows the relationship of the Review and Update Scrum Guidance Body process to the fundamental Scrum processes.
    Review and Update Scrum Guidance Body
  3. Create and Groom Program or Portfolio Backlog—In this process, the Program or Portfolio Backlog is created, updated, and maintained. Suggested improvements for the Scrum Guidance Body Recommendations may be made and implementation deadlines may be adjusted based on changed requirements and/or progress of the projects in the program or portfolio.
    Following figure shows the relationship of the Create and Groom Program or Portfolio Backlog process to the fundamental Scrum processes.
    Create and Groom Program or Portfolio Backlog
  4. Coordinate Program or Portfolio Components—In this process, components of the program or portfolio are coordinated. Dependencies between projects are addressed, common impediments are discussed, and best practices are shared. Sometimes, recommendations for improvements of the Scrum Guidance Body are made.
    Following figure shows the relationship of the Coordinate Program or Portfolio Components process to the fundamental Scrum processes.
    Coordinate Program or Portfolio Components
  5. Retrospect Program or Portfolio Releases—In this process, the Program or Portfolio Product Owner and key stakeholders get together to retrospect a program or portfolio Release and internalize the lessons learned. Often, these lessons learned lead to agreed actionable improvements to be implemented in future releases. Sometimes, improvements to the Scrum Guidance Body may be recommended.
    Following figure shows the relationship of the Retrospect Program or Portfolio Releases process to the fundamental Scrum processes.
    Retrospect Program or Portfolio Releases
Coming Soon
SBOK

A Guide to the Scrum Body of Knowledge (SBOK® Guide) provides guidelines for the successful implementation of Scrum-the most popular Agile product development and project delivery methodology. Scrum, as defined in the SBOK® Guide, is applicable to the following:

  • Portfolios, programs, and/or projects in any industry
  • Products, services, or any other results to be delivered to stakeholders
  • Projects of any size or complexity

The SBOK® Guide can be used as a reference and knowledge guide by both experienced Scrum and other product and service development practitioners, as well as by individuals with no prior experience or knowledge of Scrum or other project delivery methodology. The first chapter of the SBOK® Guide describes the purpose and framework of the SBOK® Guide and provides an introduction to the key concepts of Scrum. It contains a summary of Scrum principles, Scrum aspects and Scrum processes. Chapter 2 expands on the six Scrum principles which are the foundation on which the Scrum framework is based. Chapters 3 through 7 elaborate on the five Scrum aspects that must be addressed throughout any project: organization, business justification, quality, change, and risk. Chapters 8 through 12 cover the 19 Scrum processes involved in carrying out a Scrum project. These processes are part of the 5 Scrum phases: Initiate; Plan and Estimate; Implement; Review and Retrospect; and Release. These phases describe in detail the associated inputs and outputs of each process, as well as the various tools that may be used in each.

The Scrum Guide

Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. The Scrum Guide is maintained independently of any company or vendor and therefore lives on a brand-neutral site. Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

Find a series of resources that discuss and describe the changes between the 2017 and 2020 versions of the Scrum Guide.

SAFe

The SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe.

Achieving business agility and the benefits of Lean-Agile development at scale is not a trivial effort, so SAFe is not a trivial framework. Before realizing SAFe’s rewards, organizations must embrace a Lean-Agile Mindset as well as understand and apply Lean-Agile principles. They must identify Value Streams and Agile Release Trains (ARTs), implement a Lean-Agile portfolio, build quality, and establish the mechanisms for continuous value delivery and DevOps. And, of course, the culture must evolve as well.

Based on proven organizational change management strategies, the SAFe Implementation Roadmap graphic and article series describe the steps or “critical moves” an enterprise can take to implement SAFe in an orderly, reliable, and successful fashion.