Last updated 27/07/2021
Scrum is the most widely used agile framework worldwide. Almost three quarters (72%) of the companies that took part in the 13th Annual State of the Agile survey, stated that Scrum is their framework of choice.
Scrum refers to a framework that makes for effective collaborations among teams that are working on complex products. Although it is most often used by software development teams, scrum can essentially be beneficial to any team that is working toward a common goal. In particular, scrum is a collection of meetings, roles, and tools that work together to help teams better structure and manage their workload.
Scrum is based on 3 pillars:
Project-related tasks must be visible to all team members (transparency). The tasks should be reviewed regularly (inspection) and adjusted when needed (adaptation).
Scrum also has a set of values:
Team members dedicate themselves to their tasks (commitment) per iteration. During the iteration, the tasks will not be changed (focus). To work optimally, the team must communicate well with each other (openness and respect).
Development Team (or simply ‘Team’) refers to any team member that is not a Product Owner or a Scrum Master. They are the team members developing the features. The Development Team should be self-organized and cross-functional. That means that the Development Team has a full say on how they do the development work, in which order they pull tasks from the Sprint Backlog, and how they make decisions.
The Product Owner is business-oriented and functions as the Voice of the Customer. They have contact with the internal or external customer to find out what features are of most value to the end-user. The Product Owner owns the Product Backlog and the Product Vision. Because they understand both the business and communicate with customers, they are responsible for maximizing the value of the product or service for the end-user.
The Scrum Master is a facilitator and a coach to the rest of the team. They help the teams to do their work by removing any impediments or barriers that prevent project activities from being done. They teach the Scrum concepts to the team if necessary, and coach team members in communication. They ensure that Scrum events are successful.
To be effective in Scrum, some terms need to be defined clearly at the start of the project. Although some elements of Scrum are ridged (certain artifacts and events must be used) some elements are flexible. These flexible elements need to be decided upon before a project can start.
A project-driven in Scrum team consists of ‘Sprints’. A sprint is a timeboxed event. Sprint is the name given to an iteration in Scrum. During the Sprint, the number of tasks and scope of the tasks cannot be changed – this is to ensure the team can keep focused. However, the items on the Product Backlog can still be reviewed, revised, or removed.
A timebox is the specific amount of time that has been agreed on beforehand. This time may not be extended under any circumstances. The goal is to ensure the timeboxed events are as short as possible, but still as long as necessary. For example, a Daily Scrum should not be longer than 15 minutes. Time-boxing this event creates a habit for the team to keep to the 15-minute limit not get side-tracked or distracted.
The Definition of Done guarantees that there are no misunderstandings on when a Sprint or a task may be called ‘done’. Scrum team members must clearly state up-front what the requirements are for something to be Done so that both the customer and the team understand and agree.
Scrum artifacts are created to support the visibility of tasks (transparency) and streamline the work. There are three primary artifacts:
A product increment is the next piece of working code. It is the sum of all items from the Product Backlog that meet the Definition of Done within a specific time. A Product Increment must be “shippable”, in other words, the customer must be able to use the feature. Every Sprint, a potentially shippable set of features, is delivered.
The Product Backlog is an ordered list of all tasks that together deliver the features the customer needs or desires. This list should be clear and easy to understand. Tasks that produce the most value for the customer should be at the top of the Product Backlog. They are the features that should be done as soon as possible. The Product Backlog has no end since it can change and evolve throughout the project. Tasks can be added, removed, and revised throughout the project. That is the core of agile working! There is no need for a final version of the Product Backlog to start developing. As soon as the first items are added to the list, development can be started.
During the sprint planning meeting (defined below), the first items are selected from the product backlog. This selection is based on items’ priority and estimated teamwork and capacity. A detailed delivery plan and a sprint goal are also attached. These elements make up the sprint backlog.
There are four timeboxed events within the Scrum framework:
Each event has its purpose, such as organizing the tasks that have to be done, reviewing the progress, solving bottlenecks, or giving and receiving feedback. Scrum events are also known as ceremonies.
Sprint Planning is also a timeboxed event. The goal of the meeting is to discuss the features and tasks that should be a part of the next Sprint. The Sprint Backlog must consist of the Product Backlog items that are chosen during the Sprint Planning. Part of the Sprint Planning is estimating how many of the Product Backlog items at the top of the Product Backlog fit into the Sprint.
A Daily Scrum is a short team meeting that happens every day, at the same time, in the same place. During this meeting, each team member will address three questions:
The Sprint Review is a timeboxed meeting where the Scrum Team members present the work of the last Sprint that fits the Definition of Done. The main goals of the meeting are to collect feedback from the customer and to raise change requests as soon as possible.
During a Sprint Retrospectives, the Scrum Team looks back on the Sprint. They celebrate what went well and discuss what could be improved. These improvements could be related to processes, ways of development, communication, and presentations made to stakeholders. Any agreed-on changes should be implemented in the next Sprint.
A burn-down chart can be used to see the amount of remaining work in a Sprint. Usually, the amount of work remaining in the Sprint is plotted against the number of working days in a bar-chart. The bar should be lower after every workday, which is why it is called a burn-down chart.
The burn-up chart does something similar to the burn-down chart. It shows the cumulative amount of work done, plotted against the workdays in a bar chart. Whenever a new item is considered Done, the bar on the chart rises.
This is a concept used to determine the working capacity of a Scrum team. For example, 8 hours a day are considered regular working hours. However, some of these hours are used for planning, meetings, unplanned work, or social interactions and cannot be considered ‘product/service-developing-building hours.’ It is more reasonable to expect that team members get to work 6 out of the 8 hours available on the product or service.
Release Planning is a mid-to-long-term plan made for all products or services. It does not matter whether the customer is within the business or in the external market. Product owners make the plan based on the feedback from customers. With this, the product owner drafts upcoming shippable increments. While doing so, they have to create a balance between quality, time, budget customer value, and resources.
Release Planning helps businesses to prepare communications and marketing material beforehand and to successfully launch new features, products, or services.
Story Points are a measurement of the relative effort it takes to finish a Product Backlog item. The Product Backlog item usually takes the form of a User Story, which is why the unit of estimation of the effort is called story points. The number of Story Points the Development Team dedicates to an item is based on the effort it takes relative to other items. An item that is 8 Story Points should be 8 times as much work as an item with 1 Story Point. The definition of 1 Story Point may differ per Team and must be agreed upon beforehand.
A User Story is a way to write Product Backlog items. It describes a need from the end-user of your product or service. User Stories include how fulfilling this need would help the end-user with what they are trying to achieve. This helps the developer to understand the needs of the customer.
A User Story follows the following format: As a [customer role], I want to do [an action] to [purpose or goal].
Example: As a user of the EXIN candidate portal, I want to add my proof of training to get my certification faster without using more than one communication channel.
Velocity is a measure of the pace of the Team. The Velocity is based on the average amount of work the Team completes each Sprint. An example of a Velocity is 80 Story Points per Sprint. Computing the Velocity after each Sprint helps the Team to determine how much work can be done in future Sprints.
Starting with Scrum is easy. Being successful with Scrum, however, requires all Development Team members to have a basic understanding of agile ideology and knowledge of Scrum concepts and events. The Product Owner and Scrum Master need specialized expertise and mastery of specific skills to properly fulfill their roles. For anyone else involved in Scrum projects, which includes end-users, it is very beneficial to have a grasp of the basics.
NovelVista Learning Solutions is a professionally managed training organization with specialization in certification courses. The core management team consists of highly qualified professionals with vast industry experience. NovelVista is an Accredited Training Organization (ATO) to conduct all levels of ITIL Courses. We also conduct training on DevOps, AWS Solution Architect associate, Prince2, MSP, CSM, Cloud Computing, Apache Hadoop, Six Sigma, ISO 20000/27000 & Agile Methodologies.
* Your personal details are for internal use only and will remain confidential.
|AWS Solution Architect Associates|
|SIAM Professional Training & Certification|
|ITIL® 4 Foundation Certification|
|DevOps Foundation By DOI|
|Certified DevOps Developer|
|PRINCE2® Foundation & Practitioner|
|ITIL® 4 Managing Professional Bridge Course|
|Certified DevOps Engineer|
|DevOps Practitioner + Agile Scrum Master|
|ISO Lead Auditor Combo Certification|
|Microsoft Azure Administrator AZ-104|
|Digital Transformation Officer|
|Certified Full Stack Data Scientist|
|Microsoft Azure DevOps Engineer|