image

Scrum framework

The Scrum framework relies on 6 principles that must be followed throughout every project. The Scrum framework guidance demands that each principle remains intact and adhered to. Failing to do so risks the integrity of the method and the results it can produce.
Scrum framework

Introduction

Scrum is a lightweight Agile framework that helps people, teams, and organisations generate value by collectively discovering solutions for complex problems. The Scrum framework is made up of values, principles, roles, artefacts, and tools. Each is an important facet of the framework that makes the Scrum framework what it is.

Everything in the article below is covered in more detail in our Scrum training.

Scrum values

Agile Scrum values are described in the Agile Manifesto and serve as a compass for decision-making and team dynamics. Teams that align their mindset with the Scrum values are better positioned to deliver value to their customers.

The Scrum values are:

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect.

Successful use of the Scrum framework depends on staff incorporating these values in their day-to-day work, mindset, and interactions. Here’s how you might use these values to improve the way you work.

Commitment

Committing to working together with others to deliver a product which realises value for the customer.

Focus

Focusing on an aspect of your work, such as communication, always remaining aware of the way you talk with others and focusing on improving your ability to speak clearly and openly.

Openness

Learning to communicate your failures to others and being honest about the way you work and what personal limitations might reduce productivity.

Respect

Always being mindful of the language you use and the way you address others.

Courage

Being willing to accept your faults and work towards changing and bettering yourself rather than ignoring flaws in your character.

Scrum framework principles

The Scrum framework relies on 6 principles that must be followed throughout every project. The Scrum framework guidance demands that each principle remains intact and adhered to. Failing to do so risks the integrity of the method and the results it can produce.

The six principles are as follows.

Control over the empirical process

In the Scrum framework, the improvements made to the process are based on observation and experimentation rather than theory.

Self-organisation

Every Scrum Team member is encouraged to work independently. The self-organisation principle makes it easier to assess individual contributions.

Collaboration

The Scrum framework has 3 dimensions of collaboration: awareness, articulation, and appropriation.

Value-based prioritisation

This principle involves organising and prioritising backlog items based on their value. This ensures projects always deliver business value.

Time-boxing

This refers to the Sprints and everything else that must be done to facilitate the work in each Sprint, such as Planning and Retrospectives.

Iterative development

A project may need to be refined multiple times during the development process. The Scrum framework allows the team to adjust and manage change more easily.

Scrum events

The Scrum framework defines several events are the ‘meat’ of the Scrum method. To the untrained, it may seem as though some of these can be excluded from the Scrum framework, or otherwise combined into fewer meetings.

This is a common mistake often made by those untrained in Scrum, who do not recognise the intended use of these discussions, and how to gather information and apply lessons learned through Scrum events.

Each event is a vital part in the correct application of Scrum. If you enroll in a Scrum training course, you’ll learn how to utilise all the following Scrum tools.

Scrum Sprint

Sprints are the ‘doing’ part of the Scrum framework, where plans are turned into products. Sprints have a fixed length and can last anywhere from a few days to a month.

All the work necessary, including Sprint Planning, Sprint Reviews, Scrum development, and Sprint Retrospectives, happen within the fixed timeframe of each Sprint.

There are some important rules to Sprints that must be observed to maintain consistency:

  • No changes can be made to the Sprint plan that might interfere with achieving that Sprint’s desired goal.
  • Quality requirements must always be met, which may require renegotiating the scope with the Product Owner as necessary.

Most Sprints last 1 week, which should provide the Scrum Master and project managers with just enough information to help plan and refine the next Sprint.

Sprint Planning

Sprint Planning is explained in detail in the Scrum Guide. This stage initiates the Sprint and defines what is to be achieved over the next week (or however long the team has decided the Sprint to be).

The plan is created collaboratively by consulting with the Scrum Team and Product Owner to identify the most important backlog items and how they might contribute to the overall project goals.

Daily Scrum

The Daily Scrum is an adaptation of agile stand-up meetings. The team discusses progress toward the Sprint Goal and adjusts planned work as necessary.

This meeting should take no more than 15 minutes for the Developers from the Scrum Team. Scrum Masters (and Product Owners if present) also participate as team members, not managers.

Sprint Review

Sprint Reviews occur at the end of each Sprint. In these meetings, the Scrum Team presents the results of their work to key stakeholders. They discuss what was achieved and what changes occurred in the project environment.

Scrum Master and Product Owners use this information to address the backlog and plan the next Sprint.

Sprint Retrospective

Scrum Masters use Sprint Retrospective to improve productivity and efficiency in following Sprints by looking at interactions between individuals, processes, and tools.

Developers discuss what went well during the Sprint, what went wrong, and how they can improve their ways of working for future Sprints.

Scrum Artefacts

Scrum’s artefacts provide transparency and opportunities for inspection and adaptation and must be made readily available to all members of the Scrum Team.

Product Backlog

The Product Backlog is an ordered list of what tasks need to be done to complete the project or product.

All Product Backlog items need to be short enough to be completed in one Sprint (although a Sprint can sometimes be as long as 1 month). If they cannot be completed in one Sprint, the Scrum Team must refine Product Backlog items into smaller, more precise items with the help of the Product Owner.

Multiple Scrum Teams can work together on the same product by sharing a single Product Backlog.

Sprint Backlog

The Sprint Backlog includes the Product Backlog items selected for the Sprint and a plan on how best to complete the chosen tasks.

The Sprint Backlog is planned by the development team. It should also be planned in enough detail that Developers can inspect their progress in the Daily Scrum.

Scrum Roles

Product Owners ensure that the Developers in Scrum Teams are given direction. The Product Owner tells Developers what needs to be delivered in the next Sprint but has no control over how they achieve set goals.

The Product Owner needs to understand customer and understand how the Scrum Team is positioned to deliver value. They balance the needs of stakeholders with the organisation’s capacity to work and create products.

Their most important responsibility is to prioritise Backlog items. Conflicting priorities can reduce the effectiveness of the Scrum Team and may even lead to changes to the Scrum Team structure, work products, and end results.

Even when multiple Scrum Teams and Scrum Masters are assigned to work on a single project, only a single Product Owner can decide what works get done and when.

Scrum Master

The Scrum Master serves as a mediator between the Product Owner and the Scrum Team. They help developers improve their work and achieve goals faster by removing anything that might impede a developer’s work. They’re also responsible for ensuring that all Scrum events are held on time.

They also assist the organisation by helping them understand what the Scrum framework is and create an environment that supports Scrum.

Becoming a Scrum Master is a popular step for experienced developers to take.

Developers

The Scrum Team contains Developers – the staff that do the work. On non-software projects, the Scrum Team doesn’t just refer to IT staff. It’s an all-inclusive term that may include graphic designers, content writers, and other roles.

Scrum Developers are somewhat unique, however, in that they have limited control over the Backlog. They help Product Owner refine the Backlog and break down tasks into more manageable chunks that can be completed in a single Sprint. They also work closely with Scrum Masters to resolve issues and remove anything that might hamper their productivity.

This website use cookies.