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 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:
- What can be done in this Sprint?
- 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:
- What did I do yesterday that assisted towards the Sprint Goal?
- What will I do today that assists towards the Sprint Goal?
- 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.
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