ÆGILITY

Developing Agile Organisations to Maximise Business Value

  • Training and Certification
  • Agile Coaching and Transformation
  • Articles and Posts
  • About US
    • ÆGILITY
    • Memberships and Partners
You are here: Home / finaplana Agile Lexicon / Scrum framework

Scrum framework

Scrum framework

The Scrum framework (Scrum) is a popular framework for developing, delivering and sustaining complex products.

Scrum was developed by Ken Schwaber and Jeff Sutherland, it is offered freely and supported by a large international community of practitioners with many resources including books, websites and courses being available.

Definition of Scrum

Scrum is defined as “a framework in which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”.

The full definition of Scrum, including its roles, events, artefacts and the rules that bind them together, is contained in the Scrum Guide. This document is the definitive description of the key elements of Scrum. The Scrum Guide is translated and available in over 30 languages.

Scrum Framework Guide

Scrum is a Framework

Scrum is NOT a process, technique nor definitive method. Scrum IS a framework within which you can apply processes and techniques.

According to the the Scrum Guide, Scrum is:

  • Lightweight
  • Simple to understand
  • Difficult to master

The Scrum framework consists of Scrum teams and their associated roles, events, artefacts, and rules. The rules of Scrum are crucially important, as they bind together the other elements, and hence the Scrum Guide is also referred to as “The Rules of the Game”.

Uses for Scrum

Scrum is used in a wide variety of contexts. At its core, Scrum utilises a small team of individuals who work together to deliver regular incremental updates or changes to a product or service.

The Scrum framework aligns with many of the principles defined in the “Manifesto for Agile Software Development“, however Scrum is used in many areas outside of, and additional to, software development.

Some of the areas where Scrum is used to manage complex work include:

  • Managing organisations
  • Schools
  • Government
  • Marketing
  • Software development
  • Development of new hardware
  • Autonomous vehicles

Basis for Scrum

Scrum is based on the concept of empiricism, or “empirical process control theory”. This means that the knowledge relating to Scrum is based on experience and making decisions based on what is currently known. Scrum uses an incremental and iterative approach, which is designed to optimise predictability and control risks.

Three pillars of empirical process control underly every implementation, including Scrum.

Transparency

Transparency is a key theme of the Scrum framework. The transparency pillar requires that significant aspects of the process must be visible to those responsible for the outcome, and requires that those aspects be defined by a common standard.

This is especially true when considering scaling Scrum to larger teams, for example using the Nexus framework, as it is imperative that all participants share a common understanding of what is being delivered.

Inspection

Artefacts should be inspected frequently, to detect undesirable variances. However, it is recommended that inspection is not undertaken so frequently as to interfere with the work being delivered.

Adaptation

Based on the results of inspection, adjustments must be made as soon as possible to minimise further deviation.

Scrum Values

Scrum Teams are encouraged and expected to embody and live by five values:

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect

Successful use of Scrum, depends on team members becoming proficient in and “living” these five values.

Scrum Events

The Scrum framework includes four formal events, to support inspection and adaptation.

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

“Done” and “Done Increments”

The objective of a Scrum Team is to regularly deliver increments of work (features, changes, enhancements, etc.) which can be released to the target users or customers.

The team must determine the criteria which will be used to determine when an increment is considered complete, and therefore “Done”, however it is expected that a “Done Increment” can be released for use if and when required. Where multiple Scrum Teams are working jointly on a system or product release, then the teams must mutually define and agree on the definition of “Done“.

The Scrum Team and Roles

The Scrum team is central to the Scrum framework.

Scrum teams are self-organising and cross-functional.

Only three roles exist within  Scrum team:

  • Product Owner
  • Development Team Member
  • Scrum Master

Product Owner

The Product Owner is responsible for maximising the value of the work delivered by the Scrum team. In Scrum this is primarily achieved by creation and maintenance of a prioritised list of work to be delivered, which is known as the Product Backlog.

It is crucial, within the Scrum framework, that the product Owner be a single person (not a committee) and that the organisation respects his or her decisions.

The Product Owner is solely accountable for the Product Backlog, even where some of the work of maintaining the Product Backlog is delegated  to the Development Team.

Development Team

The Development Team consists of the professionals who do the work of delivering a potentially releasable “done increment”.

Only members of the Development Team can create this increment.

Note that the Product Owner and Scrum Master are not included within the Development Team, unless they are also executing work.

Development teams are structured and empowered to manage their own work and have the following characteristics:

  • Self-organising
  • Cross-functional, with all skills necessary to create a product increment
  • No titles for Development Team members
  • No sub-teams, within the Development Team
  • Accountability belongs to the entire team, regardless of specialised skills and areas of focus of individual team members

The optimal size for a Development Team is between 3 and 9 members.

Scrum Master

The Scrum Master is a servant-leader for the Scrum team. The Scrum Master is responsible for:

  • Promoting and supporting Scrum, as defined in the Scrum Guide
  • Helping everyone understand Scrum theory, practice, rules and values
  • Helping to manage outside interactions to maximise the value created by the Scrum Team

The Scrum Master serves the Product Owner, the Development Team and the organisation through leading and coaching them in a number of areas, including:

  • Understanding of goals, scope and product domain
  • Effective backlog management
  • Product planning
  • Removing impediments
  • Correct running of Scrum events
  • Adoption of Scrum

Scrum Events

The Scrum framework includes four formal events, to support inspection and adaptation. All Scrum events are time-boxed, which means that each event has a maximum duration.

The Sprint

All activities within Scrum are performed within an overall time-box of one month or less, called a Sprint, in which a usable and potentially releasable increment of work is delivered.

The Sprint is often referred to as the “heart” of Scrum.

All of the other activities within Scrum occur within the context of a Sprint. Each Sprint has a clearly defined goal and a fixed duration. During a Sprint:

  • No changes are made that would endanger the goal of this Sprint
  • Quality goals do not decrease
  • Scope may be clarified and renegotiated between the product Owner and the Development Team, as more is learned

A Sprint is never longer than one calendar month. This helps to ensure regular inspection and adaptation and reduces the risk and cost of change and variation from quality or requirement goals.

Cancelling a Sprint

A Sprint may only be cancelled prior to the end of the time-box with the agreement of the Product Owner. This can occur if the goal of the Sprint becomes obsolete, however it is uncommon and not recommended to cancel a Sprint unless absolutely necessary.

Any “done” items which are releasable are reviewed by the Product owner and incomplete work is placed back onto the Backlog.

Sprint Planning

Sprint Planning is a time-boxed event which occurs at the beginning of a Sprint and lasts for a maximum of eight hours for a one-month Sprint.

The Scrum Master should ensure that the event takes place and that attendants understand its purpose. The Scrum Master also teaches the Scrum Team to keep within the time-box.

Sprint Planning answers two questions:

  1. What can be done in this Sprint?
  2. How will the chosen work get done?

The Development team is responsible for determining what it can achieve over the Sprint. The Development Team also works together with the Product Owner to define a Sprint Goal, which is an objective set for the Sprint.

The Sprint Goal helps provide the Development Team with a clearly defined objective which assists in collaboration between team members and in identifying possible variance in work being done and the desired scope.

Once the Sprint Goal has been agreed, the Development Team creates a plan for how this will be achieved. The Product Backlog items selected for this Sprint, along with the plan for delivering them, is called the Sprint Backlog.

Daily Scrum

The Daily Scrum is a 15 minute time-boxed event for the Development Team. The Daily Scrum is held every (working) day during a Sprint and is used to inspect progress and plan activities for the next 24 hours.

The Development Team is responsible for defining the structure of the meeting. A typical structure involves each member of the team answering three questions:

  1. What did I do yesterday that assisted towards the Sprint Goal?
  2. What will I do today that assists towards the Sprint Goal?
  3. What impediments prevent me, or the team, from meeting the Sprint Goal?

The Daily Scrum helps to improve communications and ensure everyone in the Development Team is clear about what needs to be done next, to ensure the Sprint Goal is achieved.

Sprint Review

The Sprint Review is a time-boxed event which occurs at the end of a Sprint and lasts for a maximum of four hours for a one-month Sprint.

The Scrum Master should ensure that the event takes place and that attendees understand its purpose. The Scrum Master also teaches the Scrum Team to keep within the time-box.

The purpose of the Sprint Review is for the Scrum team and stakeholders to collaborate on inspecting the outcome of the Sprint and revise the Product Backlog to allow for any feedback and changes required.

The Sprint Review also helps the Scrum team to identify potential product Backlog items for delivery in the next Sprint.

Sprint Retrospective

The Sprint Retrospective is a time-boxed event which occurs at the end of a Sprint, usually after the Sprint Review, and lasts for a maximum of three hours for a one-month Sprint.

The Scrum Master should ensure that the event takes place and that attendees understand its purpose. The Scrum Master also teaches the Scrum Team to keep within the time-box.

The purpose of the Sprint Retrospective is for the Scrum team to inspect its own activities and to create a plan for improvements to be implemented for the next Sprint.

The Scrum Master participates in this meeting as an active member of the Scrum Team and helps encourage a positive and constructive tone. The key activities of the Sprint retrospective are:

  • Inspect how the last Sprint went
  • Identify major items that went well and potential improvements
  • Create a plan for improvements

Scrum Artefacts

The artefacts of Scrum are designed to maximise transparency and opportunities for inspection and adaptation.

Product Backlog

The Product Backlog is an ordered list of all of the requirements relating to the product or enhancement being delivered. Some key features of the Product Backlog include:

  • Contains all features, function, requirements, enhancements and fixes to be made in future release
  • It is a “living” document, which is constantly evolving and is never “complete”
  • Higher priority items are usually described in more detail and with more precise estimates
  • Multiple Scrum teams share a single Product Backlog

The Product Backlog is continually refined, with more detail, estimates and order being added to the items in the list. Items may be removed, when they are no longer relevant, and new items added as requirements evolve. This process is called Backlog Refinement and can also be known as Backlog Grooming or Backlog Management.

Sprint Backlog

The Sprint Backlog is a subset of the product Backlog items which have been selected by a Scrum Team for delivery within a particular Sprint, along with details as to how this will be delivered.

As described in the section on Sprint Planning, once the Sprint Goal has been agreed, the Development Team creates a plan for how this will be achieved. The Product Backlog items selected for this Sprint, along with the plan for delivering them, is called the Sprint Backlog.

The Development Team modifies the Sprint Backlog throughout the Sprint, and thus the Sprint Backlog emerges during the Sprint. Only the Development Team can change the Sprint Backlog during the Sprint.

Empiricism and Monitoring Progress

Within the Scrum framework, the importance of empiricism is stressed in relation to all decisions being made. The transparency inherent in Scrum helps to make progress and work remaining visible to stakeholders and this can assist in decision making and estimating. In Scrum, only “what has already happened” can be relied on for forward decision making.

Notes

Scrum is one of many frameworks freely available for use by individuals and organisation wanting to improve delivery of products or the way they operate.

The Scrum framework is focussed on roles, events, artifacts and rules relating to organisation of small teams. Whilst it is possible to implement parts of Scrum, the result is not “Scrum” and is sometimes referred to as “Scrum-But” (i.e. we do Scrum but …).

This is not to say, that changing or enhancing Scrum is wrong. The Scrum Guide states that Scrum “functions well as a container for other techniques” and, equally, other techniques can add value to the use and implementation of Scrum.

Indeed some Agile practitioners, including finaplana AG, recommend combining concepts from Kanban along with Scrum, into a hybrid framework known as Scrumban, to improve team effectives.

The Scrum framework does not address questions or issues retailing to scaling to larger teams, nor many other aspects of organisational structure. Various approaches to “scaling” are also available, including the Nexus framework, developed by Ken Schwaber and Scrum.org.

For a more comprehensive approach to scaling and organisational agility, please refer to the XSCALE framework for organisational agility.

For more information on the Scrum framework …

Please refer to the Scrum.org website and the Scrum Guide.Scrum.org Scrum framework

 

 

 

 

This page is part of the ÆGILITY Agile Lexicon
Please advise any updates or corrections by emailing the information to lexicon@aegility.ch
Whilst every effort is made to ensure correctness of the information, ÆGILITY and Lyaeus GmbH take no responsibility for the accuracy of the information or its use

Newsletter and Updates

Sign up to get our latest news and updates on our new courses!

Your contact information will never be shared by us to anyone without your consent!

Recent Posts

  • Kanban
  • RATS and CATS: maximising value delivery
  • What is “Scrum” – The Scrum Framework
  • What are “Agile” and “DevOps”, really?
  • Certified XSCALE Product Management Coach – Prof. Dr. Andres Claudius Pfister

Tags

4 Lenses of Innovation Agile Agile Manifesto Agile Metrics Agile Organisation Agile organization Agile product management Andres Claudius Pfister Avaloq AG Ayaval AG CATS Certification Culture DevOps eXponential Agile Performance Exponential Return extropy finaplana finaplana AG Game without Thrones IAP ImpactHub Zürich - Colab Introduction to Agile Kanban Leadership as a Service Lego Philosophy Principles RATS ROI ROROI Scrum Scrum Framework Self-managing Simple Design Swiss Agile Association XAP XPM XPMC XPMP XSCALE XSCALE Alliance XSCALE Product Management ZHAW

About Us

ÆGILITY is the coaching and training arm of Lyaeus GmbH and  specializes in the application of Agile Organisational values and principles to both our own company and … Read more

  • Email
  • Facebook
  • LinkedIn
  • Twitter

Latest News

Kanban

Kanban is a strategy for optimizing the flow of stakeholder value through a process that uses a visual, work-in-progress limited, pull based system. The name comes from the … Read more

Connect With Us

Lyaeus GmbH
Bahnhofstrasse 33
8703 Erlenbach (ZH)
Switzerland

T: +41 78 600 8995

E: info[at]lyaeus.ch

Copyright © 2025 Lyaeus GmbH . Company Details . Data Security Policy · Powered by Lyæus

We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies. However you may visit Cookie Settings to provide a controlled consent.
Cookie settingsACCEPT
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
Save & Accept