Agile Frameworks - Scrum

About The Author & The Article

Jonathan Bishop, Group Chairman, Bishop Phillips Consulting. [1]

Copyright 2020-2026 - Moral Rights Retained.

This article may be copied and reprinted in whole or in part, provided that the original author and Bishop Phillips Consulting is credited and this copyright notice is included and visible, and that a reference to this web site (http://RiskWiki.bishopphillips.com/) is included.

This article is provided to the community as a service by Bishop Phillips Consulting www.bishopphillips.com.

Definition: What It Is & What It Isn't

Scrum is a lightweight product development framework in the Agile philosophical epoch that aims to create 'adaptive solutions to complex problems'. It asserts that knowledge and hence value comes from shared experience (which requires transparency) and making decisions on what is observed while minimising waste and focussing on essentials. Minimising waste flows, in part, from discovering missteps as early as possible in the process (transparency again). Complexity is broken down into incremental steps (realised in 'sprints') that are time constrained (to force them to be small and keep investment low before course change is required). Ideally task steps should represent an evaluable endpoint - like a screen mock-up (perhaps without functionality) so ideas and endpoints can be incrementally refined. It adopts a project organisation structure that aims to realise these concepts within the structure itself as well as the product design.

There was a phrase there that is deliberately selected and easy to miss: Scrum is a 'product development framework'. It is NOT a project management method. It is a component of a project management method, but it omits a group of essential components required for a full project management solution in the 'real world'. It addresses a portion of project organisation that is often glossed over in project management approaches and it fundamentally re-orients the thinking of managing deliverables but it does not address all of what is required. Scrum deliberately avoids:

• budgets
• schedules
• resource allocation
• risk registers
• governance structures
• critical path analysis

These belong to:

• BPCPM
• PRINCE2
• SAFe
• organisational governance
• portfolio management

In fact Scrum implicitly assumes the project goal is defined, and the project is already staffed and resourced. Scrum's focus is on how teams deliver value, not how the organisation funds them.

The idea that Scrum means "we don't plan - we just iterate" is a dangerous anti-pattern. This is how projects blow up. Scrum reduces risk through empiricism, but it does not replace:

• risk identification
• mitigation planning
• dependency management
• financial oversight

We still need these.

How Do We Approach these Omissions?

Handling Risk

BPC's success in project management over three decades was predicated on the incorporation of active management of risk in projects. We cannot countenance a model that does not incorporate active risk management, so in this discussion we address that ommission directly.

In the guide below we have sewn into the Scrum components the responsibilities that are needed in a real-world project that are omitted from the Scrum guide and the published Scrum training materials. We have attempted to do this while preserving the focus and objectives of Scrum, so these adjustments are not a complete solution but reflective of what has to be done at the identified role levels to integrate the Scrum framework into a larger project management method.

Steering Committees and Project managers

Still omitted but essential are the roles of Executive Sponsor/Steering Committee and Project Manager.

The Steering Committee's roles include:

• Approves funding
• Sets overall budget envelope
• Makes investment decisions
• Decides whether to continue, pivot, or stop the product
• Project risk ownership & monitoring the risk register
• Reporting to executive & board on project status

The Project manager's roles include literally the ones listed above as omitted (and a few more):

• risk identification & monitoring & advising the steering committee
• steering committee liaison
• mitigation & continuity planning
• dependency management
• project resourcing & budgeting (advice to steering committee)
• financial oversight & reporting
• contract & contractor administration
• facilitating and oversight of:
  • business, use-case & needs analysis
  • acceptance & security testing
  • rollout, documentation and user training

In a minimal project adopting Scrum as its delivery paradigm the role of Project Manager should be either separately resourced or collapsed into the Scrum Master role. We would advise against collapsing the Project Manager role into the Product Owner role as philosophically these two positions represent the buyer and the supplier and it is arguably better to retain the tension between these two roles in the interests of efficiency and accountability for deadlines and outcomes. In any-case the Scrum Master must be diligent in not confusing the two roles (project manager & scrum master) when performing Scrum Master functions as they are fundamentally different in objective. Scrum events must be preserved as exclusively 'Scrum Events' and not mixed up with project management activities or the scrum ethos will be corrupted. In this discussion we specifically do not merge the Project Management role into the Scrum as that would fundamentally distort the model. We only recognise that somewhere this role is still required - just not in Scrum itself.

The Key Components of Scrum

Scrum has three roles, five events, and three artifacts (with respective commitments) — a structure confirmed consistently across authoritative sources. These components form the entire Scrum framework; nothing more is defined in the Scrum Guide[2][3].

In the Scrum model a project is broken down into a partially ordered set of tasks, which may have sequential dependencies and priorities as defined by the product owner. These tasks start life in the 'product backlog' from which they are drawn into sprints via the 'sprint backlog' for implementation and ultimately residing in the 'increment' when they reach the 'definition of done'.

Scrum consists of:

• 3 Roles
  • Product Owner,
  • Scrum Master,
  • Developers
• 5 Events
  • Sprint,
  • Sprint Planning,
  • Daily Scrum,
  • Sprint Review,
  • Sprint Retrospective
• 3 Artifacts
  • Product Backlog,
  • Sprint Backlog,
  • Increment
• 3 Commitments tied to the artifacts
  • Product Goal,
  • Sprint Goal,
  • Definition of Done

These elements enable transparency, inspection, and adaptation — the pillars of Scrum.

The 3 Scrum Roles (Accountabilities)

1. Product Owner

Product Owner

Role

Responsibilities

Accountability: product value Characteristics: Represents the external (to the project) stakeholders Owns the Product Backlog and is responsible for: Defining and communicating the Product Goal (the value outcome rather than just a deliverable) The definition of the product that achieves that goal Defining and communicating the measurement and definition of product value to the team Prioritizing and refining tasks in the backlog based on value, strategy and sequential dependence Must have authority to make product decisions Should be a single person accountable for maximising product value, not a committee

Risk Responsibility: Owns: Business risk (will the product of the project deliver the expected value) Market risks Stakeholder risks Value/ROI risks Budget Responsibility: Prioritises work to maximise value within the budget Makes scope trade‑offs Communicates ROI May request more funding via the project manager or direct to the steering committee But the PO does not hire people, set salaries, or allocate headcount.

2. Scrum Master

Scrum Master

Role

Responsibility

Accountability: Team Effectiveness Characteristics: Acts as the team facilitator, teacher, coach, & mentor Ensures Scrum is understood and enacted by the team Coaches the team and organization as required Facilitate continuous goal focus & team self-management Project administration Removes impediments and escalates same to the product owner as required Facilitates Scrum events, in particular daily standup team meetings Inter-scrum collaboration on multi-scrum projects Ensures artifacts are created and updated Task board administration Project reporting and Liaison Preparation of status updates for product owner and stakeholders Communicating and interpreting product owner and stakeholder feedback to the team Assist the product owner with backlog prioritisation decisions

Risk Responsibility: The Scrum Master is responsible for project process & implementation risks and owns: Process risks Impediments Organisational blockers Team dysfunction risks Budget Responsibility Task budgets (usually time based) Sprint budget (usually time based)

3. Developers

Developers

Role

Responsibilities

Accountability: Achieving Definition of Done Characteristics: Build the Increment each Sprint Assist in planning the Sprint Backlog Undertake the work necessary to deliver the task assigned or selected. In an agentic AI augmented production the developer is responsible for prompting and managing the AI agents assembled to undertake the work and reviewing and tuning their output. Ensure work meets the **Definition of Done**

Risk Responsibility: Technical risks Architectural risks Quality risks Integration risks AI context drift minimisation AI delivery evaluation & testing framework Budget Responsibility: Individual task budget hours AI token budget

The 5 Scrum Events

1. The Sprint (the container event)

• Fixed timebox: one to four weeks
• Contains all other events
• Produces a **usable Increment**

The Agile Sprint Events & Artifacts

The Sprint is the atomic unit of progress measurement in Scrum and defines a period required to deliver an 'increment'. It is usually set to between one and four weeks with a specific 'sprint goal' to achieve. The goal should be a tangible outcome like a defined potentially releasable 'increment' of the system being developed. The scope and duration is timeboxed and cannot be altered after commencement.

Sprints should be aligned to the product vision, goals and priorities. At the completion of each sprint there is a review and retrospective stage to inspect and assess the success of the methods and approaches used in the sprint for opportunities for continuous learning and improvement.

A sprint is structured in five stages:

• Sprint Pre-Planning
• Sprint planning. A sprint goal is determined between the Scrum Master and the Product Owner in consultation with the Developers. Product backlog items are selected based on the sprint goal and added to the Sprint backlog.
• Daily Scrum. The daily scrum is a 15 to 30 minute daily stand-up meeting during which the developer team:
  • Coordinates resources as needed
  • Identifies and (if possible resolves) impediments
  • Seeks clarification
  • Agrees immediate priorities and shares progress
• Sprint Review. Held at the completion of each sprint with all the stakeholders, the review inspects the increment the team is releasing, gathering stakeholder and testing feedback and updating the product backlog as required. The sprint review is focussed on the increment released rather than the effectiveness of the processes used to produce it.
• Sprint retrospective. Held after review at the end of sprint, the retrospective focusses on the processes of the sprint itself and is a continuous improvement function assessing what went well and what can be improved resulting in an improvement implementation strategy to be employed in the next sprint. The retrospective also reviews the project direction and tunes the product backlog if necessary to align the project with shifts in project requirements

2. Sprint Planning

• Defines the **Sprint Goal**
• Selects Product Backlog items for the Sprint
• Creates the Sprint Backlog plan

 [Agilemania](https://agilemania.com/tutorial/essential-elements-of-scrum)

3. Daily Scrum

• 15‑minute daily inspection of progress
• Developers adjust the plan toward the Sprint Goal

 [Agilemania](https://agilemania.com/tutorial/essential-elements-of-scrum)

4. Sprint Review

• Inspect the Increment with stakeholders
• Adapt the Product Backlog based on feedback
• Review risks and mitigation strategies

 [Agilemania](https://agilemania.com/tutorial/essential-elements-of-scrum)

5. Sprint Retrospective

• Inspect team processes, tools, and collaboration
• Identify improvements for the next Sprint
• Review risks and mitigation strategies

 [Agilemania](https://agilemania.com/tutorial/essential-elements-of-scrum)

The 3 Scrum Artifacts (with Commitments)

Overview

Artifacts are the 'physical' documents produced by the process. There are two backlogs which are essentially ordered lists of 'work items' to be undertaken and the third artifact is increment being built. Each artifact has a linked 'commitment'. We will explore the backlogs in more detail below.

The Commitments

A commitment in Scrum is a guiding objective that gives each Scrum artifact a clear purpose and a measurable target. It ensures the team knows why the work exists and what success looks like.

Commitments in Scrum are about alignment, not guarantees.

A commitment in Scrum has a very specific meaning. It is not a promise to deliver a fixed scope, a contract or a guarantee of output. A commitment is a stabilising anchor attached to each artifact. It provides clarity, focus, and transparency — not pressure.

Scrum deliberately avoids the old project‑management meaning of “commitment.” A Scrum commitment is not:

• a deadline
• a fixed scope promise
• a contract
• a guarantee of output
• a personal pledge
• a performance metric

Scrum commitments are team‑level alignment tools, not pressure mechanisms. They exist to solve three problems:

1. Lack of clarity
   Teams often don’t know what they’re trying to achieve.
2. Lack of transparency
   Stakeholders can’t see what “done” means.
3. Lack of focus
   Teams get lost in tasks instead of outcomes.

Perhaps a better term like alignment, objective or intent could have been chosen - then we wouldn't have had to spend so much time explaining what they aren't!

There are three commitments - one for each artifact:

1. Product Goal
   Commitment for: Product Backlog
   Meaning: A long‑term objective for the product. It gives direction and coherence to the entire backlog. Think of it as the “north star.”
2. Sprint Goal
   Commitment for: Sprint Backlog
   Meaning: A single, unifying objective for the Sprint. It explains why the selected work matters. It is not a promise to finish every PBI — it’s a promise to pursue the Sprint Goal.
3. Definition of Done (DoD)
   Commitment for: Increment
   Meaning: A shared quality standard that every Increment must meet. It ensures transparency and prevents “half‑done” work. This is the only commitment that is truly binary: Done or not done.

The Artifacts

1. Product Backlog

• Ordered list of everything needed for the product
• Continuously refined
• Commitment: Product Goal

2. Sprint Backlog

• Selected Product Backlog items for the Sprint
• Plan for delivering the Increment
• Commitment: Sprint Goal

3. Increment

• The sum of all completed work
• Must be usable and meet the 'Definition of Done'
• Commitment: Definition of Done

Backlog Items

Backlog items breakdown into tasks (usually in the sprint backlog), but they are more intended to represent 'value' rather than just effort. One backlog item might equal one task in the sprint backlog but it is generally better to break them down into at least three tasks - eg. setup, implement & test. Backlog items drive planning, forecasting and value delivery so they are a little more than the traditional kanban.

A good backlog item would contain:

Backlog Items

No.	Item	Description
1	Title	A short, clear label that should communicate the essence at a glance. Description: “Add MFA to login process”
2	Description	A concise explanation of the need, problem, or value. This is not a detailed spec — just enough context for conversation. Example: “Users need stronger authentication to reduce account takeover risk.”
3	Value / Purpose (the ‘Why’)	Scrum Guide emphasises value above all. This is the most commonly missing field. Example: “Improves security posture and meets compliance requirements.”
4	Acceptance Criteria	Clear, testable conditions that define “done.” This is literally the 'Definition of Done'. This is essential for transparency and forecasting. Example: MFA required on next login Supports SMS and authenticator apps Works on mobile and desktop Logged in audit trail
5	Size / Estimate	Scrum uses estimation for forecasting, not commitment. Usually story-points or T‑shirt sizes. Example: 5 points or Medium
6	Example	Example
7	Example	Example
8	Example	Example
9	Example	Example
10	Example	Example
11	Example	Example
12	Example	Example
13	Example	Example
14	Example	Example
15	Example	Example
16	Example	Example

Why these components matter

Scrum is intentionally minimal. The combination of:

• **roles** (clear accountability)
• **events** (regular inspection/adaptation)
• **artifacts** (transparency of work)

creates an empirical system that allows teams to navigate complexity and deliver value iteratively. [deckary.com](https://deckary.com/blog/scrum-framework-guide)

BackLinks

• Main Page
• Enterprise Agile Transformation
• Agile Frameworks - Embedding Agentic AI into Scrum
• Agile Frameworks - SAFe