Scrum Framework

Scrum Framework Principles

The Scrum principles provide the core guidelines for applying the Scrum framework and should mandatorily be used in all Scrum projects. The six Scrum principles 2 are:

1. Empirical Process Control 
2. Self-organization 
3. Collaboration 
4. Value-based Prioritization 
5. Time-boxing 
6. Iterative Development

The below Illustrates the Six Scrum Principles.

You can apply Scrum framework principles to any type of project in any organization. You must adhere to them in order to ensure effective implementation of the Scrum framework. These non-negotiable Scrum Principles must be applied as specified in the SBOK™ Guide which can be found in our Scrum Certificate Courses.

Keeping the principles intact and using them appropriately instills confidence in the Scrum framework with regard to attaining the objectives of the project. The Scrum aspects and processes, however, can be modified to meet the requirements of the project or the organization.

1. Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.

2. Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership. This makes an innovative and creative environment more conducive for growth

3. Collaboration—This principle 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.

4. Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from beginning early in the project and continuing throughout.

5. Time-boxing—This principle describes how one considers time as a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum framework includes Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.

6. Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

Scrum Aspects

The below five Scrum aspects must be addressed and managed throughout a Scrum project.

• Organization
• Business Justification
• Quality
• Change
• Risk

More on these below...

Organization

Understanding the defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum.

Scrum roles falls into two broad categories:

1. Core Roles—The project mandatorily requires these roles for producing the project’s product or service. Individuals assigned to these core roles fully commit to the project. They are ultimately responsible for the success of each project iteration and of the project as a whole.

These roles include:

• The Product Owner achieves maximum business value for the project. He or she articulates customer requirements and maintains business justification for the project. The Product Owner represents the Voice of the Customer. 
• The Scrum Master ensures an environment conducive to completing the project successfully for the Scrum Team. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project. He clears impediments for the team; and, ensures they follow the Scrum processes.
• The Scrum team understands the requirements specified by the Product Owner and creates the Deliverables of the project.

2. Non-core Roles—Non-core roles, not mandatorily required for the Scrum project, may include interested team members  in the project. They have no formal role in the project team and may interface with the team, and may not be responsible for the success of the project. However, the Scrum project must take into account any

• Stakeholder(s), includes customers, users, and sponsors They frequently interface with the Scrum Core Team, and influence the project throughout the project’s development. Most importantly, the project produces the collaborative benefits for the stakeholders.
  
• Scrum Guidance Body (SGB) is an optional role. It generally consists of a set of documents and/or a group of experts typically involved with defining the objectives related to quality, government regulations, security, and other key organizational parameters. This SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team. 
• Vendors, including external individuals or organizations provide products and/or services that are not within the core competencies of the project organization. 
• Chief Product Owner is a role in bigger projects with multiple Scrum Teams. This person facilitates the work of multiple Product Owners, and maintains business justification for the larger project. 
• Chief Scrum Master coordinates Scrum-related activities in large projects which may require multiple Scrum Teams to work in parallel.

The below illustrates the Scrum Framework Organization Structure.

The Organization aspect of Scrum also addresses the team structure requirements to implement Scrum in programs and portfolios.

Business Justification

An organization must perform a proper business assessment prior to starting any project. This helps the 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.

You base the business justification in the Scrum framework is on the concept of Value-driven Delivery. One of the key characteristics of any project is the uncertainty of results or outcomes. Given, one cannot guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, 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.

Scrum framework adaptability allows the project’s objectives and processes to change if its business justification changes. Note, that although the Product Owner is primarily responsible for business justification, other team members contribute significantly.

Quality

In Scrum, we define quality as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.

To ensure a project meets quality requirements, Scrum framework adopts an approach of continuous improvement whereby the team learns from experience. Stakeholder engagement constantly keeps the Prioritized Product Backlog updated with any changes in requirements.

The team never completes The Prioritized Product Backlog 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.

Scrum requires work completed in increments during Sprints. This means that errors or defects get noticed earlier through repetitive quality testing, rather than during the near completion of the final product or service. Moreover, the Scrum Team completes important quality-related tasks (e.g., development, testing, and documentation) as part of the same Sprint. This ensures inherent quality in any Sprint deliverable.  The team refers to such potentially shippable deliverables as ‘Done.’

Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project.

Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with the actual increments of Sprint deliverable, ensures a constantly reduced gap between customer expectations from the project and actual deliverables.

Change

Every project, regardless of its method or framework used, is exposed to change. Because of this, project team members must 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 a) stakeholders (e.g., customers, users, and sponsors) change their minds about what they want and need throughout a project (sometimes referred to as “requirements churn”) and b) 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. This enables the customer to regularly interact with the Scrum Team members.They view deliverables when ready, and change requirements, as needed, earlier in the Sprint.

Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.

Risk

We define Risk as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks likely to have a positive impact on the project are referred to as opportunities. Whereas threats refer to risks that could affect the project in a negative manner.

Managing risk must be done proactively. This iterative process begins at project initiation and continue throughout the project’s lifecycle. The process of managing risks should follow some standardized steps.  This ensures that the team identifies, evaluates, and acts upon a proper course of action accordingly for the risks.

One identifies, accesses. and responds to risks based on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence. Risks with a high probability and impact value (determined by multiplying both factors), should be addressed before those with a relatively lower value. In general, once the team identifies a risk, importantly one must understand the risk with regard to the probable causes and the potential effects if the risk occurs.