The Core Principles of Scrum | David Tzemach
Updated: Mar 3, 2022
Scrum is based on six core principles that make it the most common, successfully implemented framework. In this article, I will give you my perspective and how to use them to increase the effectiveness of your Agile development process.
Principle 1: Self-organized & Cross-functional teams
Although rare in reality, the Scrum framework states: “Scrum Teams are self-organizing and cross-functional.” These two aspects are critical in the Agile environment as they provide the bassline for a successful team that can:
Work as a single unit without the need directed by external stakeholders.
Have all the knowledge, experience and tools to meet their goals.
Work in harmony, flexibility and creativity to handle complex projects.
Principle 2: Empirical process control
Scrum uses empirical process control based on the real-world progress of a project, not on the guesses or long-term forecasts used in traditional methodologies.
By using empirical process control, project decisions are made based on observations and experiments rather than on detailed upfront planning. This principle has three pillars:
Pillar 1: Transparency
Allows any stakeholders to get a clear view of the project details without assumptions. This promotes the flow of information throughout the organization and facilitates an open culture where anyone can view all work activities. Specifically, in Scrum, we enable this through different techniques such as prioritized product backlogs, burndown charts, daily meetings, etc.
Pillar 2: Inspection
Within the Scrum framework, this is achieved by:
Specific measurements that can provide critical information about the overall progress of the project (e.g., quality KPIs, team velocity).
Continuous feedback loops from the customer and other stakeholders during the development cycles (Sprints).
Review and approval of team deliverables by the Product Owner.
Pillar 3: Adaptation
This is the last part of empirical process control. It occurs as the organization learns through continuous improvement. In Scrum, this is done by having retrospectives, constant risk analysis, and specific change requests.
Principle 3: Continuous feedback
The continuous feedback process is a critical element in the Scum Framework. There is less upfront planning to guide the team throughout the project development life cycle. Instead, the team relies on continual feedback to understand and respond to changes and keep the project on track.
The framework provides an excellent platform for allowing continuous feedback loops, using events (Review, Retrospective, Etc.) and artifacts (Product and Sprint Backlogs, Burn-Down charts, etc.), For example:
Sprint review - As part of this meeting, the team will share sprint results and get feedback from the PO/customer about the quality of the work. This feedback is then translated into new product backlog items that will help provide a better product.
Sprint Burn-Down chart – The Release Burn-Down chart provides excellent feedback about the remaining and completed work for a given point in time.
Principle 4: Iterative approach for delivering rapid releases
According to the framework, teams should use development sprints that can last between a week and a month. A Scrum team will follow four phases per Sprint. These are elaborated in the sections below:
Phase 1 – Sprint Kick-off
Every Sprint begins with a planning meeting involving the entire Scrum team (Development, SM and PO). The meeting’s outcomes will include:
Sprint backlog containing a list of prioritized stories.
List of tasks created per story to guide the development activities.
A clear definition of the Sprint goal.
Phase 2 – Sprint Execution
The team will work together as a single unit to deliver the stories they committed to completing by performing various research, coding, and testing activities. These are mandatory as part of almost every story. Using these activities, the team can ensure each story will meet the Definition of Done (i.e., DoD) and will be able to accomplish the sprint goal determined at the beginning of the sprint.
Phase 3 – Continuous feedback based on sprint results
At the end of each sprint, the team will demonstrate the potentially shippable product increment to the relevant stakeholders (Product Owner, Customer, etc.). They will gain feedback and approval for the quality of their work (this feedback will be used as input for the next sprints.).
Phase 4 – Continuous improvement
In the end, the team will perform a retrospective meeting. During this meeting, they will discuss how things went, improvements needed in future sprints, and the main impediments preventing them from flourishing.
Principle 5: Continuous value to the customer through prioritization
Scrum ensures the customer is at the center of the process as an Agile approach. Scrum teams should provide deliverables to the customer at the end of each development sprint throughout the project. The deliverables must be based on backlog prioritization (Led by the Product Owner) of user requirements (features and stories). This will enable the team to deliver maximum value to the customer.
"Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software." (Agile Manifesto)
Principle 6: Timeboxing to increase predictability
Each Agile project is based on little upfront planning; this makes it more adaptive to changes but less predictable. The project must use a predictable schedule with small repeatable time-boxes to achieve a high productivity level.
A “Timebox” is an agreed and limited period used by a person/team to perform a dedicated activity. Once the Timebox is decided and set, the team/person works to complete a goal within this time. If the time ended without completing all the activities required, continuing will depend on the time-box approach (Soft Vs. Hard).
For example, let's take an Agile project with 100 units of work the team needs to deliver. The team velocity is completing five units every two weeks (The time box of the sprint). By knowing these fundamental factors, the organization can predict the completion of the project using a simple formula of timeboxing/velocity = twenty Sprints.