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
| Role | Responsibilities |
|---|---|
Accountability: product valueCharacteristics:
|
Risk Responsibility:Owns:
Budget Responsibility:
But the PO does not hire people, set salaries, or allocate headcount. |
2. Scrum Master
| Role | Responsibility |
|---|---|
Accountability: Team EffectivenessCharacteristics:
|
Risk Responsibility:The Scrum Master is responsible for project process & implementation risks and owns:
Budget Responsibility
|
3. Developers
| Role | Responsibilities |
|---|---|
Accountability: Achieving Definition of DoneCharacteristics:
|
Risk Responsibility:
Budget Responsibility:
|
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 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)
1. Product Backlog
- Ordered list of everything needed for the product
- Continuously refined
- **Commitment:** *Product Goal*
[teachingagile.com](https://teachingagile.com/scrum/psm-1/scrum-framework)
2. Sprint Backlog
- Selected Product Backlog items for the Sprint
- Plan for delivering the Increment
- **Commitment:** *Sprint Goal*
[teachingagile.com](https://teachingagile.com/scrum/psm-1/scrum-framework)
3. Increment
- The sum of all completed work
- Must be usable and meet the **Definition of Done**
- **Commitment:** *Definition of Done*
[teachingagile.com](https://teachingagile.com/scrum/psm-1/scrum-framework)
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)
