How Scrum can be implemented effectively?

Introduction

Scrum is one of the most popular Agile frameworks. It is an adaptive, iterative, fast, flexible, and effective framework designed to deliver significant value quickly throughout a project. Although the Scrum framework is primarily used to deliver projects and create products, Scrum may also be used to manage the continuous maintenance of products and services, track issues, and manage changes. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The Scrum framework helps to deliver product features independently, allowing the team to focus on delivering high-value functionality first. We can say that 80% of a product’s value resides in roughly 20% of its features.

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

Overview of Sprint

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision gets 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 selected to be included in the Sprint. A Sprint generally lasts between one and four weeks and involves the Scrum Team is working to create potentially shippable deliverables or product increments.

During the Sprint, short, highly focused Daily Standup meetings are conducted in which team members discuss daily progress. The Product Owner can assess completed deliverables during the Sprint and can accept the deliverables that meet the predefined Acceptance Criteria. Towards the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant business stakeholders are provided a demonstration of the deliverables.

The Sprint cycle ends with a Retrospective Meeting in which the team members discuss ways to improve the way they work and their performance as they move forward into subsequent Sprints.

Empirical Process Control

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control aids learning through experimentation when the problem is not well-defined or when there are no clear solutions. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through the Project Vision Statement, Prioritized Product Backlog, Sprint Backlog, Release Planning Schedule, etc. The team’s progress can be made clearly visible through the use of a Scrum board, Burndown Chart, and other information radiators.

During Sprint Planning Meetings the Scrum Team estimates the effort needed to deliver top priority User Stories and commits to a set of User Stories for completion in the Sprint. During the Daily Standup meetings, all team members report what they have done the previous day, what they plan to do today, and any problems that prevent them from completing their tasks in the current Sprint. During the Sprint Review meetings, the Scrum Team demonstrates the potentially shippable Sprint Deliverables to the Product Owner and business stakeholders.

Sprint Retrospective meetings are conducted after the Sprint Review Meetings on the final day of the Sprint during which the Scrum Team discusses improvement opportunities for future Sprints. A Release Planning meeting or session is conducted to enable the Scrum Team to have an overview of the planned releases and delivery schedule for the product they are developing.

Inspection

Inspection in Scrum is depicted through the following:

Use of a common Scrum board and other information radiators that show the progress of the Scrum Team on completing the tasks in the current Sprint.
Collection of feedback from the customer and other business stakeholders during the Develop Epic(s), Create Prioritized Product Backlog, Conduct Release Planning and Refine Prioritized Product Backlog processes.
Inspection and approval of the deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

Adaptation

Adaptation happens as the Scrum Core Team and business stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Some examples of opportunities for adaptation in the Scrum framework include:

In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. More experienced members of the Scrum Team also mentor those with relatively less experience in knowledge of the project or technology.
Risk identification is performed and iterated throughout the project. Identified risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Refine Prioritized Product Backlog, and Demonstrate and Validate Sprint.
Improvements can also result in Change Requests, which are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Refine Prioritized Product Backlog processes.

The Scrum Guidance Body interacts with Scrum Team members during the Create User Stories, Estimate Tasks, Create Deliverables, and Refine Prioritized Product Backlog processes to offer guidance and also provide expertise as required.

In the Sprint Retrospective meetings, agreed actionable improvements are determined based on the outputs from the Demonstrate and Validate Sprint process.
In the Retrospect Release Meeting, participants document lessons learned and perform reviews looking for opportunities to improve processes and address inefficiencies.

Self-organization

Scrum practices embrace the idea that employees are self-motivated and seek to accept greater responsibility. So, employees will deliver greater value when self-organized. Self-organization does not mean that team members are allowed to act in any manner that they want to. Once the Project Vision is defined, the Product Owner, Scrum Master, and Scrum Team are identified. Also, the Scrum Core Team itself works very closely with relevant business stakeholders to refine requirements better. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project. Although prioritization is primarily done by the Product Owner who represents the Voice of the Customer, the self-organized Scrum Team is involved in task breakdown and estimation. Each team member is responsible for determining what work he or she will be doing. The Scrum Team also helps the Product Owner identify risks and dependencies.

Self-organization as an essential principle in Scrum has the following benefits:

Team buy-in and shared ownership
Motivation, which leads to an enhanced performance level of the team
Innovative and creative environment conducive to growth
Selection of the simplest and best approach to satisfy given requirements

Collaboration

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the business stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. Collaboration occurs when a team works together to produce something of greater value. To achieve full collaboration, it is important to establish trust between all team members and between the team and the business stakeholders.

Collaboration ensures that the following project benefits are realized:

The need for changes due to poorly clarified requirements is minimized.
Risks are identified and dealt with efficiently.
Efficiency is increased. For example, the daily standup provides an opportunity for the Scrum Team to collaborate and understand the strengths and weaknesses of its members.
Continuous improvement is ensured through lessons learned. For example, the Scrum Team uses the Sprint Retrospective meeting to identify what went well and what did not go well in the previous Sprint. This provides an opportunity for the Scrum Master to work with the team to rework and improve the team for the next scheduled Sprint. This will also ensure that collaboration is even more effective in the next Sprint.

Scrum of Scrums Meeting

A Scrum of Scrums meeting is an important element when scaling Scrum to large projects. The objective of most Scrum of Scrum meetings is the synchronization of teams during the creation of deliverables, but could also be used for sharing best practices after Retrospect Sprint Meetings, and for planning future Sprints. The frequency of SoS meetings is project-specific and depends on project size and complexity, dependencies between different teams, etc. If Epics or User Stories in Sprints can be completed without too much interaction with other Epics or User Stories, these meetings may not be required too often. However, if the dependencies are high, then a higher frequency of SoS meetings may be required.

Value-based Prioritization

Scrum uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework. It helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims to deliver a valuable product or service to the customer on an early and continuous basis. Prioritization is done by the Product Owner who prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to completion.

Time-boxing

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are:

Efficient development process
Fewer overheads
High velocity for teams
More focused teams
Well-prepared team members

Iterative Development

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. To achieve this practically, the Scrum application involves the iterative development of deliverables. The iterative model is more flexible in ensuring that any change requested by the customer can be included as part of the project. User Stories may have to be written constantly throughout the duration of the project.

In the initial stages of writing, most User Stories define high-level functionalities and these are known as Epics. An Epic is usually too large for teams to complete in a single Sprint. Therefore, they are broken down into smaller User Stories. Each complex aspect of the project is broken down through progressive elaboration during the Refine Prioritized Product Backlog process. The Create User Stories, Estimate User Stories, and Commit User Stories processes are used to add new requirements to the Prioritized Product Backlog.

The Product Owner’s task is to increase ROI by focusing on value and its continuous delivery with each Sprint. The Product Owner should have a very good understanding of the project’s business justification and the value the project is supposed to deliver as he/she drafts the Prioritized Product Backlog and thereby decides what deliverables and hence value are delivered in each Sprint. Then the Identify Tasks, Estimate Tasks, and Update Sprint Backlog processes produce the Sprint Backlog which the team uses to create the deliverables.

In each Sprint, the Create Deliverables process is used to develop the Sprint’s outputs. The Scrum Master has to ensure that the Scrum processes are followed and facilitate the team to work in the most productive manner possible. The Scrum Team self-organizes and aims to create the Sprint Deliverables from the User Stories and tasks in the Sprint Backlog. In large projects, various cross-functional teams work in parallel across Sprints, delivering potentially shippable solutions at the end of each Sprint. After the Sprint is complete, The Product Owner accepts or rejects the deliverables based on the Acceptance Criteria in the Demonstrate and Validate Sprint process. The benefit of iterative development is that it allows for course correction as all the people involved get a better understanding of what needs to be delivered as part of the project and incorporate this learning in an iterative manner. Thus, the time and effort required to reach the final endpoint is greatly reduced and the team produces deliverables that are better suited to the final business environment.

Technical Debt

Technical debt represents the cost of additional rework caused when a team chooses a quick and easy solution over a more difficult but potentially more beneficial one. It is a result of compromises made in software development, leading to higher costs when these issues have to be fixed. If technical debt is not checked regularly, it can lead to slower development times, lower code quality, and reduced productivity. Hence, managing and reducing technical debt is essential for a high-performing Scrum team. Technical Debt can be reduced through a combination of proactive and reactive measures.

Proactive measures include implementing high coding standards, conducting regular code reviews, and investing time in proper design and documentation.

Reactive measures are like prioritizing and scheduling a time to fix known issues. Regular refactoring i.e. restructuring existing code without changing functionality is also a good approach to reduce technical debt.

Both proactive and reactive measures require a solid foundation of well-defined, integrated data. Ideally, the data should be available with a common data model so intelligence can be extracted by leaders and team members without a deep understanding of data engineering. A data-driven, systematic approach to address technical debt can significantly enhance a Scrum team’s efficiency and productivity thereby increasing the business value delivered.

Different Roles in a Scrum Team

Scrum roles fall into two categories:

Core Roles: Core roles are those roles that are mandatorily required for producing the project’s product or service. Individuals who are assigned core roles are fully committed to the project and are responsible for the success of each sprint and that of the project as a whole.

Core roles comprise the Scrum Core Team members, which include:

The Product Owner is the person responsible for achieving maximum business value for the project. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.
The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and ensures that Scrum processes are being followed.
The Scrum Team is the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the deliverables of the project.

Non-core Roles: Non-core roles are those roles that are not mandatorily required for the Scrum project. They may include team members who are interested in the project but have no formal role in the project team. These individuals may interface with the team but may not be responsible for the success of the project. The non-core roles should be taken into account in any Scrum project.

Information Radiators

An information radiator is a comprehensive display of key team information, openly shared with all team members and other stakeholders, and gets updated regularly.

Common information radiators used in scrum environments are Product vision, Product Backlog, Release Plan, and Sprint backlog.

Scrumboard shows the ongoing progress of the sprint. The team uses a Scrum board to plan and track progress during each Sprint.

Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint in relation to the remaining time.

A Burnup Chart depicts what has been completed in relation to the remaining time.

All these information radiators help a scrum team visualize and conclude the value delivered by the team over a period of time.

Kaiburr connects to all the tools used by software teams and provides 360-degree visibility on performance using 350+ KPIs and 700+ best practices. Some of the metrics can be seen below –