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 in the context of the Project Management Eco-system

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].

The foundational resource (artifact) from which all Scrum activity flows is the Product Backlog controlled by the Product Owner and representing his 'wish list' of things that need to be delivered by the project team. The Product Backlog is a list of Product Backlog Items (PBI's) or value outcomes for delivery and the purpose of the Scrum team is to realise value by clearing the Product Backlog of the items it contains - translating opportunity for value-add into realised value-add.

PBI's Are Not Tasks

In the Scrum model a project is broken down into a partially ordered set of Product Backlog Item's (PBI) which are 'outcome items' or 'value deliverables' (not quite tasks), which may have sequential dependencies and priorities (defined by 'value' or inter-dependency) as defined by the product owner. These 'value deliverables' start life in the 'product backlog' from which they are drawn into sprints via the 'sprint backlog' for breakout into tasks and implementation and ultimately residing in the 'increment' when they reach the 'definition of done'.

While seemingly 'task-like' a PBI (value deliverable) and task are different because it is a 'unit of outcome value' for which a number of 'units of work' (i.e. tasks and sub-tasks) may be required to realise.

An example may help clarify this concept: "Enhance login process with MFA" might be seen as a PBI (value outcome) and placed on the project backlog, and drawn into a sprint backlog, where it is then expanded into a set of tasks required to achieve that deliverable like: 'assess MFA options', 'update the login screen', 'liaise with telco provider to confirm access', 'acquire modem', 'install modem', 'get finance approval for telecom budget', 'build connection to the messaging API', 'update the audit trail logger', 'build & run unit tests', etc. The backlog item has the value-add, while the tasks are essential to achieve the item, they don't themselves carry the value add or an allocatable portion of that value. Now in this case, there might also end up being multiple approaches (email, SMS, authenticator app, etc.) each with different costs and therefore different value-add measures, which are identified in the course of the sprint (assuming they were missed in pre-planning). In that case the developers might pursue one (as/if specified) in the current sprint and log the alternative strategies for consideration on the project backlog by the product owner, who would then assign a value and a priority for scheduling to later sprints, or refer the entire family for clarification and selection by the product owner where no option had been pre-defined. Clearly in this case there are different operating costs and effectiveness measures in play which may or may not have been considered in the original ask and might need prioritisation now.

While I prefer 'Value Deliverable' as an alternative to PBI other alternative terms that are in common use (although none of these are really complete) include:

• User Story - Useful when work is user facing. Eg. 'As a user I want X so that Y'
• Feature - Good for larger value oriented items.
• Enhancement - Useful for improvements to existing functionality
• Bug/Defect - Obvious.
• Spike - For research or investment work
• Epic - A large body of work that must be split into multiple PBI's

Whatever name is adopted, the PBI must go onto the product backlog in the first instance and should reflect:

• value (not effort)
• outcome (not activity)
• what (not how)

Scrum components

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**

2. Sprint Planning

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

3. Daily Scrum

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

4. Sprint Review

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

5. Sprint Retrospective

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

Implementing The Sprint

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. This is not really a stage of the Sprint, but something that comes before all Sprints and perhaps each Sprint. This is the initial set-up stage where resources are collected, Backlogs are reviewed for completeness & prioritisation, risks are reassessed and ratings updated, story points a reviewed and affirmed or modified, perhaps resource availability is confirmed, etc.
• 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.
• Implementation & Daily Scrum. The implementation phase is where the work gets done and it is marked by the daily scrum which 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

During implementation PBI's and their tasks are pulled from the backlog and rolled into the ready & work-in-progress columns of the Kanboard while they are acted on by the developers, ultimately moving the tasks (and the parent PBI's) to the review stage and done stages.

• 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

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.

How PBI's Relate to Sprint Goals

Why versus What

The PBI is the means by which the Sprint Goal is realised.

PBIs support the Sprint Goal — not the other way around.

Think of it like this:

• The Sprint Goal is the why
• The PBI is the what
• The Tasks are the how

During Sprint Planning, the Scrum Team first answers:

 “Why is this Sprint valuable?”

This becomes the Sprint Goal — the commitment for the Sprint Backlog. It is a single, coherent, unifying objective.

Once the Sprint Goal is defined, the team selects PBIs that:

• contribute directly to achieving the Sprint Goal
• can reasonably be completed within the Sprint
• form a coherent set of work

PBIs are chosen because they help achieve the Sprint Goal — not because they “fit the timebox.”

Only after PBIs are selected do developers break them into tasks.

So the hierarchy is:

 Sprint Goal → PBIs → Tasks

This is the correct conceptual model and this structure gives the team:

• Focus - Everyone is working toward the same outcome.
• Flexibility - If a PBI turns out to be bigger than expected, the team can renegotiate scope as long as the Sprint Goal remains achievable.
• Coherence - The Sprint is not a bucket of unrelated work — it is a purposeful step toward the Product Goal.

The anti‑pattern to avoid:

  “The Sprint Goal is to complete these 8 PBIs.”

This is not a Sprint Goal: That’s just a list.

A Sprint Goal must describe an outcome, not a collection of items.

An Example

Sprint Goal:

  “Enable secure user authentication.”

PBIs selected:

• Add MFA to login
• Implement password reset flow
• Add audit logging for authentication events

Tasks (examples):

• Build MFA UI
• Integrate SMS provider
• Write unit tests
• Update database schema

Notice how the PBIs all support the Sprint Goal, and the tasks support the PBIs.

What happens if PBIs change mid‑Sprint?

Scrum Guide:

Scope may be renegotiated with the Product Owner as more is learned, without affecting the Sprint Goal.

This is the power of the model:

• PBIs can change
• Tasks can change

The Sprint Goal stays stable as the Sprint Goal is the anchor.

The Artifacts

1. Product Backlog

• Ordered list of everything needed for the product by value
• Use story points to measure complexity
• Continuously refined
• Commitment: Product Goal

2. Sprint Backlog

• Selected Product Backlog items for the Sprint
• Plan for delivering the Increment
• May be broken down into tasks (tied to each backlog item)
• 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

The Backlog, whether product or sprint is a list of backlog items (PBI's). PBI's items breakdown into tasks (usually in the sprint backlog), but they are intended to represent 'value outcomes' (the what) rather than just effort (the how - which is the domain of tasks). 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 or task.

So what is recorded in a good PBI?

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. Example: “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	Dependencies / Constraints	Optional but extremely useful. Helps avoid surprises during Sprint Planning. Example: “Depends on user profile service refactor.”
7	Priority / Ordering	This is the Product Owner’s job. The backlog is ordered, not “ranked” or “sorted.” Example: PBI #3 in the backlog.
8	Definition of Done alignment	Every PBI must be deliverable to the DoD. This is field that would be populated in the Sprint Backlog (rather than in the Product Backlog - although it might be partially populated at that level). If it can’t meet the DoD, it must be split. There is DoD for the Sprint which should rollup the DoD's for the PBI's in the Sprint. Likewise individual Tasks will also have a DoD which (it could be argued) roll up to the PBI.
9	Business owner / stakeholder	This is the person/group who will ultimately accept the deliverable. This should include contact details or link to a contact management system.
10	Mockups or attachments	Guiding materials relating to design, presentation, behaviours, etc. This might be a link to the document management system.
11	Technical notes	Technical configuration, or advisory documentation related to the deliverable.
12	Story Points	This is a complexity measurement metric which is used to help identify how big the PBI is and hence how many PBI's can be done in a single sprint. It is discussed elsewhere in this paper.
13	Inherent Risk Rating	The inherent risk rating is the combination of the likelihood and impact of the threats to the value realisation arising from the environment before mitigation strategies are implemented. This may be a value or a link to a risk management system where threats (risk events) and mitigations (controls) are defined in detail. Accurate formulation of this contributes significantly to the steering committee responding to risk events in a timely fashion. Failure to deliver on a PBI - which is rolled up from failure to complete Tasks the meet DoD is an automatic risk.
14	Residual Risk Rating	The residual risk is the rating AFTER mitigating strategies have been applied and current active risk events applied. Eg. If a risk event is active, its probability goes from likely/unlikely to certain resulting in the impact assessment becoming 100% of the estimated impact value, but reduced by the mitigating controls. This value should be continuously monitored by the Scrum Master / Product Owner and Project Manager and ultimately the Steering Committee.
15	Workflow State	Product or Sprint workflow stage as appropriate. See discussion below.
16	Tasks	This is the task list representing the break-put of the PBI in the Sprint Backlog. In the Product Backlog this value is usually empty except as populated during pre-planning. It is relevant to the Sprint Backlog where it should be populated. It may be a swimlane link in a Kanboard which contains the detailed tasks.
17	Custom Fields	Your project might need other fields to be tracked in the PBI, for example in a larger multi-sprint Epoc this field might contain links to Sprints or PBI's running in other Product Backlogs, or project managers or parent steering committees where multiple projects/managers/steering committees are active.

A Note on Task Cards

While Remembering that Scrum does not cover task structuring or definitions, the practical reality is that in the Sprint the PBI is translated to Tasks and subtasks for implementation. So in the interests of completeness we will spare a word on the content of Task objects to help contrast the Task from the PBI.

When the PBI is broken down into tasks the task object (task card) -which may be implemented using a Kanboard, for example - would be created with additional fields more familiar to traditional project managers:

• subtasks
• detailed specifications
• effort hours
• start/end dates
• assigned developers
• workflow states beyond “in progress”

PBI Workflow States

Introduction

The Scrum guide defines no workflow states for PBIs — neither at the Product Backlog level nor inside a Sprint.

The Scrum Guide notes that:

• The Product Backlog is an ordered list of work.
• The Sprint Backlog is the Sprint Goal + selected PBIs + the plan.

The only official “states” Scrum cares about are:

• Done (meets the Definition of Done)
• Not Done (everything else)

Scrum intentionally avoids prescribing workflow states because they are context‑specific. So here we will define a set of measures that are generally workable. You should modify these as you see fit for your project management needs, but these are a good starting point.

You will need a workable set of states for efficient management and transparency and the larger or more complex the project, the more important the states will become. I see that there are two groups of workflows:

• Product Backlog Set
• Sprint Set

We will look at each in turn.

Product (Backlog) Workflow (before & after the Sprint)

Product (Backlog) States

No.	Label	Description
1.	Idea / Proposed	A raw concept, request, or need. Not refined, not sized, not ready.
2.	Defined / Described	The PBI has a clear description and value statement eg. Business case.
3.	Ready for Refinement	The team can now discuss it meaningfully.
4.	Refined	Acceptance criteria added, dependencies known, risks identified.
5.	Submitted to Steering Committee	Meets the team’s Definition of Ready (DoR): clear valuable small enough testable estimated
6.	Ready for Sprint	Steering Committee / Project Manager has accepted the proposal / business case & agreed to fund it. This is the state from which PBIs can be selected during Sprint Planning.
7.	Done	PBI has completed the Sprint and meets the definition of done (and has been accepted by the client)

Sprint Workflow (during the Sprint)

Product Backlog States

No.	Label	Description
1.	Selected for Sprint (Sprint Backlog)	Chosen during Sprint Planning because they support the Sprint Goal.
2.	Ready	Scrum Master is satisfied that Task / sub tasks have been mapped out, cross dependencies / blocks determined / non-human resources required are allocated / blockages cleared .
3.	In Progress	Developers are actively working on the PBI (and its tasks).
4.	In Review / In Testing	Work is completed but not yet meeting the Definition of Done. This may include: peer review testing integration UX review security checks
5.	Done	Meets the Definition of Done. This is the only state Scrum formally recognises.

Story Points & the Roll in PBI Selection

Definition

While 'Value' might be key metric for the Product Owner in determining priority of PBI's, the Story Points measure is a key metric for the Scrum Master and Developers in determining how much can be accomplished in each Sprint and thus the scope of the Sprint.

Story Points are a relative measure of complexity, uncertainty, and effort — a way for teams to compare work items to each other rather than guess exact durations:

• Complexity — how hard is this compared to other work
• Uncertainty — how much is unknown
• Effort — roughly how much work is involved

Teams usually use a Fibonacci scale:
1, 2, 3, 5, 8, 13…  
because complexity grows non‑linearly.

Story points do not translate linearly into time: A 5‑point story is not “5 hours” — it’s “bigger than a 3, smaller than an 8.”, however for a stable team, or an experienced developer the numbers correlate loosely to a passage of time, so an individual developer thinks of story points as an internalised relative scale. If something he rates at 3 takes a couple of days, then something he rates as five will likely take in his mind 2 to 3 times longer. There is a directional correlation but not a direct relation.

Why Use Story Points?

Story Points are used in Scrum because of a belief by the conceivers that most people are bad at estimating time for projected work. Over the years many strategies have been employed in project management to estimate the probable time requirements for coding such as line counts, function point analysis, etc. All tend to do better with extensive statistical data to underpin the calculations in a predictable and stable code base, known languages, but reliability correlates most heavily with years of experience. The more dynamic the environment, the younger the code base, the more developers who have worked on it, the less experienced the coders, the newer the development environment: the less reliable are the time estimates.

When it comes to PBI's however, the problem is much greater as at the point a PBI is being estimated it doesn't even have a task breakdown - it is a value deliverable proposition, an objective - not a plan, and certainly not a coding effort commitment vector. At this point it is really only possible to estimate the probable complexity compared to other PBI's in the list.

The idea is that while you may not be easily able to estimate how long it will take to climb hill 'A' (particularly if all you have is a vague description), you can much more reliably estimate whether hill 'A' seems bigger/harder than hill 'B'.

At the point the PBI appears on the Product Backlog an hour estimate would likely introduce a false precision, leading to unfounded commitments, encourage micro-management and most importantly undermine empiricism. Remember the point of Agile is to literally be 'agile' and allow for rapid adjustments to plans and scopes based on learnings acquired during delivery.

When Are Hour Estimates Appropriate?

In Scrum hour estimates belong only in one place:

Task breakdown inside the Sprint Backlog

Once a PBI is selected for the sprint, developers may break it into tasks and estimate hours for their own planning, not for reporting.

Example:

PBI: “Add MFA to login” — 5 story points  
Tasks:
- Add UI elements (3 hours)
- Integrate SMS provider (4 hours)
- Add audit logging (2 hours)
- Write tests (3 hours)
These hours are not tracked outside the team.

From a Project Manager's perspective, the project runs in Sprints of, say, 4 weeks with a team of N developers at a monthly cost of Y$ per Sprint. The team finds they can deliver X story points of output in that time period, so PBI's up to around X points can be allocated for each Sprint. On that basis the Project Manager can estimate the approximate cost of the PBI's in the Product Backlog at any given point.

Why these components matter

Scrum is intentionally minimal. The combination of:

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

It creates an empirical system that allows teams to navigate complexity and deliver value iteratively.

Measuring Performance in Scrum

Scrum is an empirical framework, so it relies on multiple complementary metrics to give transparency into value, flow, quality, and predictability.

Scrum metrics should measure 4 buckets of data:

• Value (are we building the right thing?)
• Flow (how efficiently does work move?)
• Predictability (can we forecast?)
• Quality (is the product healthy?)

1. Value Metrics (Most important)

Scrum is about value, not output. These metrics tell you whether the team is building the right things.

1. Sprint Goal Success Rate
   • How often the team achieves the Sprint Goal.
   Why: Measures focus, alignment, and value delivery.
   
   
2. Value Delivered per Sprint Could be:
   • business value points
   • revenue impact
   • risk reduction
   • customer satisfaction
   Why: Shows whether the product is moving toward the Product Goal.
   
   
3. Customer / Stakeholder Satisfaction
   • Surveys, NPS, feedback.
   Why: Scrum is customer‑centric.

2. Flow Metrics (Kanban‑friendly and extremely useful)

These measure how efficiently work moves through the system:
1. Cycle Time
   • Time from “work started” → “work done.”
   Why: Predictability and bottleneck detection.
   
   
2. Lead Time
   • Time from “requested” → “delivered.”
   Why: Measures responsiveness to stakeholders.
   
   
3. Work in Progress (WIP)
   • How many PBIs are being worked on simultaneously.
   Why: High WIP = slow flow, context switching, delays.
   
   
4. Throughput
   • Number of PBIs completed per Sprint.
   Why: Helps forecast delivery without story points.

3. Predictability Metrics

These help you forecast future delivery.
1. Velocity
   • Story points completed per Sprint.
   Why: Helps forecast capacity, not performance.
2. Forecast Accuracy
   • How close the team’s forecast was to actual delivery.
   Why: Measures planning realism.
3. Sprint Burndown / Burnup
   • Shows progress toward the Sprint Goal.
   Why: Early detection of scope creep or blockers.
4. Release Burnup
   • Tracks progress toward a larger Product Goal.
   Why: Helps stakeholders understand long‑term delivery.

4. Quality Metrics

Scrum requires a high‑quality Increment every Sprint. These metrics measure quality:.
1. Defect Rate / Escaped Defects
   • Bugs found after release.
   Why: Indicates quality of the Increment.
2. Technical Debt Trend
   • How much debt is accumulating or being paid down.
   Why: Predicts future slowdown.
3. Definition of Done Compliance
   • How often PBIs meet the DoD without exceptions.
   Why: Ensures transparency and quality.
4. Code Quality Metrics
   • Examples: test coverage, static analysis scores.
   Why: Supports sustainable development.

Which metrics matter most?

If you track only five, track these:

• Sprint Goal Success Rate
• Cycle Time
• Throughput
• Velocity (trend, not target)
• Defect Rate

These give you a complete picture of value, flow, predictability, and quality.

What NOT to track for Scrum(anti‑patterns)

These destroy agility:

• Hours worked
• Individual velocity
• Lines of code
• Number of tasks completed
• Story points as performance metrics
• “Commitment vs delivered” charts
• Utilisation (100% utilisation = slowest flow)

Scrum is about value, not busyness.

Creating a Dashboard For Tracking Scrum Metrics

A Scrum Dashboard would start with the 'purpose' and it should answer five questions:

• Are we delivering value?
• Are we improving flow?
• Are we predictable?
• Is quality improving or degrading?
• Are we moving toward the Product Goal?

Everything else is noise.

Choose the right metrics (not too many)

A good dashboard has 8–12 metrics, grouped by category.

• Value
  • Sprint Goal Success Rate
  • Value Delivered (business value points, risk reduction, etc.)
  • Stakeholder Satisfaction (simple 1–5 score per Sprint)

• Flow
  • Cycle Time (PBI start → Done)
  • Lead Time (request → Done)
  • Throughput (PBIs per Sprint)

• WIP (Work in Progress)
  • Predictability
  • Velocity (trend, not target)

• Forecast Accuracy
  • Sprint Burnup
  • Release Burnup

• Quality
  • Defect Rate
  • Escaped Defects
  • Technical Debt Trend
  • DoD Compliance

These give a complete picture without overwhelming you.

Design the dashboard layout (Kanboard‑friendly)

Top row: Value

• Sprint Goal Success (traffic light)
• Value Delivered (bar)
• Stakeholder Score (line)

Middle row: Flow

• Cycle Time (control chart)
• Throughput (bar)
• WIP (gauge)

Bottom row: Predictability + Quality

• Velocity (trend line)
• Forecast Accuracy (percentage)
• Defects (bar)
• DoD Compliance (gauge)

This layout mirrors how decisions are made: Value → Flow → Predictability → Quality.

Data sources (conceptually)

You don’t need complex integrations. You can derive everything from:

• PBI timestamps (Created, Started, Done)
• Sprint boundaries
• PBI metadata (value, type, estimate)
• Defect logs
• Sprint Goal outcomes
• DoD checks

How the dashboard actually works (the logic)

Cycle Time

Cycle Time = Done Date − Start Date

Throughput

Count of PBIs Done per Sprint.

Velocity

Sum of story points Done per Sprint.

Forecast Accuracy

Accuracy = Delivered Points / Forecast Points

Sprint Goal Success

Binary: Achieved / Not Achieved.

Defect Rate

Number of defects created per Sprint.

DoD Compliance

PBIs meeting DoD / Total PBIs Done

Value Delivered

Sum of value points (or risk reduction score).

The philosophy behind the dashboard

A Scrum dashboard should:

• Reveal bottlenecks (flow metrics)
• Expose risks early (quality + predictability)
• Show whether we’re building the right thing (value metrics)
• Support empirical decision‑making

It should not be a management surveillance tool.

Cover Product & Sprints

Use a dual‑layer dashboard

• Sprint Dashboard (short‑term health)
• Product Dashboard (long‑term trajectory)

With these visualisations:

• Control charts for cycle time
• Burnup charts for Sprint and Release
• Velocity trend line
• Defect trend line
• WIP gauge
• Value delivered bar chart
• Sprint Goal success indicator

And these integrations

• Pull PBI timestamps from the Kanboard (or tool used for tracking PBI / Task Kanbans)
• Use custom fields for value, risk, and DoD
• Auto‑calculate metrics at Sprint close
• Store historical metrics for trend analysis

This gives us a complete empirical control system for Scrum.

Next: Agile Frameworks - Embedding Agentic AI into Scrum

BackLinks

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