Scrum Basics

Here are the basic topics:

What is Scrum?
Negative Impacts on Projects
Why use Scrum?
History of Scrum
Scrum Sprints
Scrum Flow
Scrum Roles
Scrum Core Roles
Scrum Non-Core Roles
Framework of the SBOK Guide
Scrum Principles
Scrum Aspects
Scrum Processes

1. What is Scrum?

Scrum is a framework for developing and sustaining complex projects.
Scrum is the most popular agile project management and project development framework.
Scrum is applied by following the guidelines of the SBOK (Scrum Body Of Knowledge).
The SBOK was developed as a standard guide for organizations and professionals who want to implement Scrum, as well as those who want to make improvements to their processes.
The SBOK is a compilation of the latest methods and best practices employed by its practitioners and experts, and provides guidelines for the successful implementation of scrum.
The SBOK provides a comprehensive framework that includes the Principles, Aspects and Processes of the scrum framework.
The practicality of Scrum as a framework is that it can be applied effectively to any "project" in any industry of any size.
According to the SBOK, the term "product" may refer to a product, service, or any other deliverable.

2. Negative Impacts on Projects

All projects are impacted negatively to plan, execute, manage and ultimately succeed by constraints of:

Time
Cost
Scope
Quality
Resources
Organisational capabilities

3. Why use Scrum?

It's the most popular Agile Framework/methodology
It's an adaptive, iterative, fast, flexible and effective methodology
It's designed to deliver significant value quickly and throughout the project
It ensures transparency in communication
It creates an environment of collective accountability and continuous progress
It is structured in such a way that it supports product and service development in all types of industries and any type of project irrespective of its complexity
It helps to mitigate all negative impacts on projects

Highlighted points:
Adaptability:
Empirical process control and iterative delivery make projects adaptable and open to incorporating change.
Transparency:
All information radiators such as Scrumboard and Sprint Burndown Chart are shared, leading to an open work environment.
Continuous feedback:
Continuous feedback is provided through the Conduct of Daily Standup, and Demonstrate and Validate Sprint processes.
Continuous Improvement:
The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized Product Backlog process.
Continuous Delivery of Value:
Iterative processes enable the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.
Sustainable Pace:
Scrum processes are designed such that the people involved can work at a sustainable pace that they can, in theory, continue indefinitely.
Early Delivery of High Value:
The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.
Efficient Development Process:
Time boxing and minimizing non essential work leads to higher efficiency levels.
Motivation:
The Conduct of Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.
Faster Problem Resolution:
Collaboration and colocation of cross functional teams lead to faster problem solving.
Effective Deliverables:
The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.
Customer Centric:
Emphasis on business value and having a collaborative approach to stakeholders ensures a customer oriented framework.
High Trust Environment:
Conduct of Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.
Collective Ownership:
The Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.
High Velocity:
A collaborative framework enables highly skilled cross functional teams to achieve their full potential and high velocity.
Innovative Environment:
The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

4. History of Scrum

Framework inception in the 1980's
Developed by Hirotaka Takeuchi and Ikujiro Nonaka
They described an innovative approach to product development called the "Rugby" (or holistic) approach
It was based on the manufacturing case studies from different industries, with a flexible and all-inclusive produvt development strategy
The concept believes project development should not be like a sequential relay race, but rather should be similar to the game of rugby with back-and-forth patterns of cyclic iterations of collaborative work
In 1995, at the Object-Oriented Programming Systems Languages & Applications (OOPSLA) conference in Austin, Texas, (in a presentation) Ken Schwaber and Jeff Sutherland elaborated on the Scrum concept and how it applies to Software Development
Several practitioners, experts, and authors have continued to refine the Scrum Methodology and concept framework

5. Scrum Sprints

Sprints are short periods of time spent in which a certain amount of work which must be done. This is achieved through the use of cross-functional, self-organized and empowered Scrum Teams, who divide their works into short cycles called "Sprints".

6. Scrum Flow

STAGE 1 - Project Business Case [Initiate]
(Product Owner)
The Scrum cycle begins with the Product Owner creating a Product backlog which is a list of all the features, functions and requirements that might be needed in the final product of the project. It's a prioritized list. The items with high business value has higher priority on the list, while the low value items are given low priority.

STAGE 2 - Project Vision Statement [Initiate]
(Product Owner + Scrum Master)
Next, a Project Vision Meeting is held to discuss the Product backlog and to outline the purpose of the project, hence, the project vision is created. At this stage, the Scrum Team members are appointed.

STAGE 3 - Prioritized Product Backlog [Initiate/Plan and Estimate]
(Product Owner + Scrum Master + Scrum Team)
Next, the Scrum Team (usually between 6-10 members) get together in a sprint planning meeting (stakeholder meeting) to decide what items in the Product backlog they can prioritize and work on and complete before the next sprint period. The list of items to be worked on for the current sprint is called the Sprint Backlog.

STAGE 4 - Release Planning Schedule [Initiate/Plan and Estimate]
(Product Owner + Scrum Master + Scrum Team)
The release planning meeting is held to decide possible end dates for each Sprint cycle, and to create the Release Planning Schedule which shows potential timelines for Sprint deliverables to be reviewed and deployed. At this stage, the length of the Sprint will be agreed between the Product Owner and the Scrum Team.

STAGE 5 - Sprint Backlog [Implement]
(Scrum Team)
The list of items to be worked on for the current sprint is called the "Sprint Backlog". The development team (Scrum Team) immediately set to work to create the deliverables for the current Sprint, completing the Items in the Sprint Backlog. The Scrum Team is a group of individuals (usually between 6-10 members) who work on the User Stories in the Sprint Backlog to create the deliverables for the project. The time set to complete the Sprint Backlog task is called a "Sprint" which usually takes between 2-4 weeks to complete. The SBOK recommends a sprint period of between 1-6 Weeks.

STAGE 6 - Daily Standup [Implement]
(Scrum Master + Scrum Team)
The development team and the Scrum Master meet everyday during the Sprint for a short 15mins standup meeting called the "Daily Scrum" or Daily Standup. The daily Standup meeting is to:

Discuss their daily progress
Synchronize their activities
Identify any issues that will stop them from working, and
Plan for the work to be completed in the next 24hrs

STAGE 7 - Create Deliverables [Review and Retrospect]
(Product Owner + Scrum Master + Scrum Team)
At the end of the Sprint, in the Sprint review meeting, the Scrum team demonstrates to the Product owner and other stakeholders the output (created deliverables) of the work they have done during the current Sprint and the previous Sprints. They demonstrate the latest increments of the product which is a potentially shippable product.

STAGE 8 - Accepted Deliverables [Release]
(Product Owner + Scrum Master + Scrum Team)
The Project Owner and Scrum Master reviews the latest product increments and the potential business value, accept the created deliverables for release, and refines the Product backlog in preparation for the next iteration or Sprint. The next Sprint is initiated and the process begins again.

7. Scrum Roles

There are defined roles and responsibilities for every Scrum project, in ensuring the successful implementation of Scrum. The Scrum roles fall into two categories:

Core Roles
Non core Roles

Core Roles
Core roles are those roles which 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 ultimately responsible for the success of each project iteration and of the project as a whole.

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

8. Scrum Core Roles

In Scrum, there are 3 core roles:

Product Owner
Scrum Master
Scrum Team

Product Owner

Responsible for achieving maximum business value for project
Articulates customer requirements
Maintains business justification for a project
Represents customers’ voice

Scrum Master

Ensures that the Scrum Team is provided with an environment conducive to complete the project successfully
Guides, facilitates, and teaches Scrum practices to everyone involved in the project
Clears impediments for the team
Ensures that Scrum processes are being followed

Scrum Team

Responsible for understanding Product Owner specified requirements
Creates the project deliverables

9. Scrum Non-Core Roles

In Scrum, there are 3 non-core roles:

Stakeholder(s)
Scrum Guidance Body (SGB)
Vendors

Stakeholder(s)

Acollective term that includes customers, users, and sponsors.
Stakeholders frequently interface with the Scrum Core Team, and influence the project throughout the project’s development.
It is for the stakeholders that the project produces the collaborative benefits.

Scrum Guidance Body (SGB)

An optional role, which generally consists of a set of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters.
The SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team.

Vendors

Include external individuals or organizations, that provide products and/or services that are not within the core competencies of the project organization.

10. Framework of the SBOK Guide

The SBOK™ Guide is broadly divided into three areas of Principles, Processes and Aspects.

11. Scrum Principles

Scrum principles are the core guidelines for applying the Scrum framework and should mandatorily be used in all Scrum projects. They include (CoVIT-ES):

Emperical Process Control (E)
Self-organization (S)
Collaboration (Co)
Value-based Prioritization (V)
Time-boxing (T)
Iterative Development (I)

Emperical Process Control
This principle emphasizes the core philosophy of scrum, based on the three main ideas of Transparency, Inspection and Adaptation.
Self-organization
It focuses on today's workers, who deliver significant value when encouraged to self-organize, rather than working under command and control style of traditional project management.
Collaboration
Collaboration focuses on the three core dimensions related to collaborative work: Awareness, Articulation and Appropriation. It also advocates project management as a shared value creation process, with Teams working and interacting together to deliver the greatest value.
Value-based Prioritization
This principle highlights the focus of scrum to deliver maximum business value, beginning early in the project and continuing throughout
Time-boxing
This principle emphasizes time as a limiting constraint in scrum. Timeboxing is used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup meetings, Sprint Planning meetings and Sprint Review meetings.
Iterative Development
This principle defines iterative development and emphasizes how to better manage changes and build projects that satisfy customer needs. It also delineates the product owners and organisations responsibilities related to iterative development.

12. Scrum Aspects

The Scrum aspects must be addressed and managed throughout a Scrum project. They include (CROB-Q):

Organization (O)
Business Justification (B)
Quality (Q)
Change (C)
Risk (R)

Organization
Organization has to do with defined roles and responsibilities for every Scrum project, in ensuring the successful implementation of Scrum. The Scrum roles fall into two categories:

Core Roles
Non core Roles

In Scrum, there are 3 core roles:

Product Owner
Scrum Master
Scrum Team

In Scrum, there are 3 non-core roles:

Stakeholder(s)
Scrum Guidance Body (SGB)
Vendors

Business Justification
It is important for an organization to perform a proper business assessment prior to starting any project. This helps key decision makers understand the business need for a change or for a new product or service, the justification for moving forward with a project, and its viability.

Business justification in Scrum is based on the concept of Value driven Delivery.
One of the key characteristics of any project is the uncertainty of results or outcomes.
It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project.
Hence, Scrum attempts to start delivering results as early in the project as possible.
This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

Quality
Quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.

Acceptance Criteria are the objective components by which a User Story’s functionality is judged.
Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy.
Example: Every in progress order must be saved every 5 seconds to the logged in user account as a draft order.
To ensure a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements.
The Prioritized Product Backlog is simply never complete until the closure or termination of the project.
Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.
Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through repetitive quality testing, rather than when the final product or service is near completion.
Important quality related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team. This ensures that quality is inherent in any deliverable created as part of a Sprint.
Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Change
Every project, regardless of its method or framework used, is exposed to change. It is imperative that project team members understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that arise from change and minimize any negative impacts through diligent change management processes in accordance with the principles of Scrum.

A primary principle of Scrum is its acknowledgement that stakeholders change their mind about what they want and need throughout a project, sometimes referred to as “requirements churn”.
Another is that it is very difficult, if not impossible, for stakeholders to define all requirements during project initiation.
Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables.
Hence, the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.

Risk
Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. For example, one of the key investors in a project backs off at an important juncture. This is a risk affecting the project in a negative way and can be considered as a Threat. However, if the project finds a better investor to invest in a bigger way, it can be considered as an Opportunity. The Risk management Procedure is thus:

Risk Identification: Using various techniques to identify all potential risks.
Risk assessment: Evaluating and estimating the identified risks.
Risk prioritization: Prioritizing risk to be included in the Prioritized Product Backlog.
Risk mitigation: Developing an appropriate strategy to deal with the risk.
Risk communication: Communicating the findings from the first four steps to the appropriate stakeholders and determining their perception regarding the uncertain events.

Risks should be identified, assessed, and responded to based primarily on two factors:

The probability of an occurrence
The probable impact in the event of the occurrence

Risks with high probability and high impact rating should be addressed before those with a lower rating. In general, once a risk is identified, it is important to understand the basic aspects of the risk with regard to the possible causes, the area of uncertainty, and the potential effects if the risk occurs.

13. Scrum Processes

Scrum processes address the specific activities and flow of a Scrum project. In total there are nineteen fundamental Scrum processes that apply to all projects. These processes are grouped into five phases:

Initiate
Plan and Estimate
Implement
Review and Retrospect
Release

Initiate

Project Business Case is reviewed to create Project Vision Statement
Product Owner is identified
Scrum Master and Stakeholder(s) are identified using specific Selection Criteria
Scrum Team members are identified Product Owner is responsible for selecting team members and often does so in collaboration with the Scrum Master
Project Vision Statement serves as the basis for developing Epics
Epics are large, unrefined User Stories in the Prioritized Product Backlog which cannot be delivered in one Sprint cycle.
Personas are created to identify the needs of the target user base
Personas are highly detailed fictional characters, representative of the majority of users and of other stakeholders who may not directly use the end product.
Personas are created to identify the needs of the target user base.
Epic(s) and Unrefined User Stories are refined, elaborated, and prioritized to create a Prioritized Product Backlog
Done Criteria are also established
Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical, because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms.
Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule
Length of Sprint is determined

Plan and Estimate

User Stories and their related User Story Acceptance Criteria are created
Usually written by the Product Owner
Designed to ensure that the customer’s requirements are clearly depicted and understood
Involves Scrum Team members creating the User Stories
Incorporated into the Prioritized Product Backlog
Tells you three things about the requirement: Who, What, and Why
User Story Format: As a , I should be able to so that
Example 1: As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
Example 2: As a Web developer, I should be able to track user data through their unique login, so that I can enable customization of product and service offerings to the visitors.
Example 3: As a customer, I should be able to log in as a guest, so that I can check the offerings without registration when constrained by time.
Product Owner clarifies User Stories
Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story
Scrum Team commits to develop the customer requirements in the form of Estimated and Committed User Stories (approved by Product Owner) for a Sprint
Committed User Stories are broken down into specific tasks and compiled into a Task List.
Scrum Core Team estimates the effort required to accomplish each task in the Task List
Result of this process is an Effort Estimated Task List
The Scrum Core Team holds Sprint Planning Meetings
Sprint Backlog containing all tasks to be completed in the sprint is created
A Sprint Burndown Chart with a planned burndown is created

Implement

Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables
Scrumboard is often used to track the work and activities being carried out
Issues or problems faced by the Scrum Team could be updated in an Impediment Log
The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint.
The initial Sprint Burndown Chart is accompanied by a planned burndown.
The Sprint Burndown Chart should be updated at the end of each day as work is completed.
Everyday a highly focused and time boxed meeting is conducted. It is referred to as the Daily Standup meeting
This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing
The Prioritized Product Backlog is continuously updated and maintained
Prioritized Product Backlog Review Meeting may be held
Any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog

Review and Retrospect

Scrum Team demonstrates the Sprint Deliverables to the Product Owner in a Sprint Review Meeting
Purpose of this meeting is to secure approval and acceptance of the product or service by the Product Owner
Scrum Master and Scrum Team meet to discuss the lessons learned
Information is documented as lessons learned which can be applied to future Sprints
There may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations

Primary objectives of the Retrospect Sprint Meeting are to identify three specific items:
• Things the team needs to keep doing: best practices
• Things the team needs to begin doing: process improvements
• Things the team needs to stop doing: process problems and bottlenecks

Release

Accepted Deliverables are delivered or transitioned
A formal Working Deliverables Agreement documents the successful completion of the Sprint
Organizational stakeholders and Scrum Core Team members assemble to retrospect the project, Identify, document, and internalize the lessons learned
Lessons lead to documentation of Agreed Actionable Improvements to be implemented in future projects

For Scaling Scrum for Large Projects and Scaling Scrum for the Enterprise, that require coordination across multiple teams, there are eight additional Scrum processes that are grouped into two phases:

Scrum for Large Projects
Scrum for the Enterprise

Scrum for Large Projects

Scrum for the Enterprise

#End

Hope you enjoyed this! :) Follow me for more contents...

Get in Touch:
ifeanyiomeata.com
contact@ifeanyiomeata.com

Youtube: youtube.com/c/IfeanyiOmeata
Linkedin: linkedin.com/in/omeatai
Twitter: twitter.com/iomeata
Github: github.com/omeatai
Stackoverflow: stackoverflow.com/users/2689166/omeatai
Hashnode: hashnode.com/@omeatai
Medium: medium.com/@omeatai
© 2021**

Scrum Basics

By Ifeanyi Omeata