You have completed the Agile Fundamentals course. This guide maps the topics that were intentionally left out — too advanced for a first course — and shows you exactly where to find them when you are ready.
The Agile Fundamentals course was designed for people with no prior knowledge. It gave you the concepts and practices you can start using immediately: the Agile mindset, the Scrum framework, planning with User Stories and User Journeys, running and monitoring Sprints, and handling everyday situations that every Agile team faces.
A number of topics were deliberately set aside — not because they are unimportant, but because they only make sense after you have worked in an Agile team for some time. They are the difference between understanding something in the abstract and understanding it from experience. This guide covers each of those topics and tells you where to find the best material on each one.
Agile mindset, Scrum framework, User Stories, sprint execution, backlog management, and stakeholder communication. These are the core — use them first.
Transformation leadership, the change curve, middle management dynamics, and scaling frameworks. These land differently once you have seen real team behaviour.
SAFe, LeSS, flow metrics (cycle time, lead time), OKRs as a full framework, portfolio management, and Agile coaching as a discipline.
The course covered burndown charts for Sprint-level tracking. Once you are managing releases across multiple Sprints, you will need a second tool: the burnup chart.
A burnup chart shows two lines over time: work completed (rising from zero) and total scope (ideally flat). The gap between them is the remaining work. Its advantage over a burndown is that scope changes become immediately visible — if the scope line rises, someone added work, and you can see exactly when and by how much. A burndown hides scope creep; a burnup exposes it.
Start with burndowns for Sprint tracking. Move to burnups when you are managing a release with four or more Sprints and stakeholders are asking about overall progress, not just the current Sprint. The burnup answers "are we on track to finish the whole release?" while the burndown answers "are we on track to finish this Sprint?"
Story points and velocity give you a rough picture of capacity. Flow metrics give you a precise picture of how work actually moves through your system. The two most important are:
How long a single item takes from the moment the team starts working on it to the moment it is done. A low, consistent cycle time means work is flowing well. High variance means unpredictability — some stories take a day, others take three weeks, and you don't know why.
How long from when a request is made to when it is delivered. Includes the time the item spends waiting before the team even picks it up. Stakeholders care about lead time; the team cares about cycle time. Both matter.
The best resource on flow metrics is "Actionable Agile Metrics for Predictability" by Daniel Vacanti. Dense but directly practical once you have run several Sprints.
The course's Session 8 focused on what Agile looks like on your team. Spreading it to a whole organisation is a different challenge — one that involves leadership behaviour, middle management dynamics, resistance patterns, and cultural change. This is the territory most Agile courses lead with. This course put it here deliberately, because it makes far more sense after you have seen a real team work.
The most common failure pattern is "doing Agile" without "being Agile" — adopting ceremonies and tools without changing how decisions are made, how failure is treated, or how success is measured. The specific failure modes, in order of frequency: leadership that announces Agile but continues demanding annual plans; ceremonies without mindset (standups as status reports, retrospectives with no action); the middle management layer feeling threatened by self-organising teams; and transformation outsourced to consultants who leave behind a playbook the organisation doesn't understand.
People who resist Agile adoption are usually responding rationally to a real threat: their job stability, their established expertise, or their sense of authority. The change curve model describes the stages people move through: shock and denial → resistance → exploration → commitment. Understanding which stage someone is at changes how you communicate with them — not as a manipulation technique, but because different stages call for genuinely different responses.
The best resource here is "Fearless Change" by Mary Lynn Manns and Linda Rising — a practical pattern language for introducing new ideas into organisations.
The layer most directly affected by self-organising teams is middle management — and it is usually the layer least consulted in transformation planning. Managers who derived authority from coordinating work find the coordination function absorbed by the team. The productive path is not to eliminate the role but to reframe it: an Agile manager enables, coaches, and removes organisational impediments that teams cannot address themselves. This is a harder job — not a lesser one.
After you have worked in an Agile team for at least 3–6 months, you will have direct experience of these dynamics. The leadership and middle management content that feels abstract before that experience becomes immediately recognisable after it. Read "Fearless Change" then — not before.
Once you have multiple Agile teams working on a single product, coordination becomes a challenge. Scaling frameworks attempt to solve this. Each makes different trade-offs, and each is widely misapplied. The most important principle: add the minimum structure needed to coordinate the dependencies you actually have. Never scale for the organisation you imagine you will become.
A lightweight coordination mechanism where one representative from each team meets regularly to surface cross-team dependencies. No new roles, no new ceremonies beyond the coordination meeting. This is the right first step before any more complex framework is introduced. If Scrum of Scrums is not working, the problem is almost always a process or communication issue, not a framework issue.
Multiple teams working from a single Product Backlog with one Product Owner. Adds minimal process beyond standard Scrum. The appeal is simplicity; the challenge is that it requires an exceptionally capable PO and strong team discipline. Easier to understand than SAFe; harder to execute than it appears. Best for 2–8 teams on one product.
Tribes, Squads, Chapters, Guilds — a famous team topology that Spotify used at a particular moment in its growth. The people who created it have explicitly stated it is not a prescriptive framework and should not be copied wholesale. It is useful for thinking about team structure and culture; not useful as an implementation guide. Search for "Henrik Kniberg Spotify Model misunderstood" before applying any of it.
A comprehensive, prescriptive system covering team, programme, and portfolio levels. Includes its own roles (Release Train Engineer, Business Owner), ceremonies (PI Planning), and artefacts. Best suited to large enterprises with regulatory compliance requirements and many teams that need coordinated quarterly planning. The criticism — that it frequently installs a new kind of bureaucracy — is legitimate. Do not adopt SAFe without first having experienced teams that can hold the complexity without the framework becoming the product.
The course covered the distinction between output thinking ("we shipped 47 features") and outcome thinking ("users complete their key task 40% faster"). OKRs are the most widely used formal framework for operationalising outcome thinking at a team and organisational level.
An OKR has two parts. The Objective is a qualitative, ambitious, and inspiring statement of what you want to achieve: "Make QuickBite the most trusted food delivery experience in the city." The Key Results are specific, measurable outcomes that tell you whether you achieved the objective: "Increase repeat order rate from 34% to 55%", "Reduce customer support contacts per order from 0.8 to 0.3", "Achieve a net promoter score of 45+."
OKRs measure outcomes — things that happen to users — not outputs like features shipped or velocity achieved. An OKR that says "ship the payment redesign" is not an OKR; it is a task. The question is: what will change for users if the payment redesign works? That is your Key Result.
The best introduction is "Measure What Matters" by John Doerr — the book that popularised OKRs at Google and most of Silicon Valley. Read it after you have been working with a backlog for at least six months; the examples will land completely differently.
The course introduced technical debt as a concept: shortcuts taken during development that make future work harder. Managing it properly — not just acknowledging it exists — is a senior Agile practitioner skill.
The key practices: keep technical debt visible on the backlog as first-class items (not hidden in a separate spreadsheet), budget a percentage of each Sprint specifically for debt reduction (typically 10–20% of velocity), and make the business case for paying it down in terms the PO and stakeholders understand — "every hour we spend on debt now saves three hours of new feature work in six months."
The hardest part is not identifying the debt — it is justifying time to reduce it when stakeholders want new features. The framing that works: technical debt is a risk to the delivery forecast. A team carrying high debt delivers less per Sprint over time, not more. Paying it down is not a cost; it is an investment in velocity.
Read "Working Effectively with Legacy Code" by Michael Feathers when you are ready for the technical depth. For the product and PM side of the conversation, "Continuous Delivery" by Jez Humble and David Farley is the definitive treatment of how to build and maintain systems that stay fast to change over time.
These are the books that most directly extend what the course covered. Ordered by when to read them — not by importance.
The product mindset that underpins genuine Agile adoption. Ries makes the case for validated learning as the primary measure of progress — not features shipped. The first three chapters alone change how you think about what to build and why. Start here.
Patton invented story mapping. The book explains not just how to build a map but how to use it to discover what to build. The first three chapters change how you think about backlogs. Directly relevant to what the course covered in Sessions 5 and 6.
13 pages. Free at scrumguides.org. The official source of what Scrum actually says — not what any particular trainer or tool vendor interprets it to say. Read it once after every six months of practice; it gets clearer each time.
Sutherland is one of Scrum's co-creators. Accessible, practical, full of implementation stories. The chapters on impediment removal and team dysfunction become immediately recognisable once you have been in a real Sprint.
A practical pattern language for introducing Agile practices into resistant organisations. Each pattern is a named, repeatable approach. Most useful once you have encountered actual resistance — which usually happens around month three.
The definitive introduction to OKRs. Full of case studies from Google, Intel, and others. The framework will make much more sense after you have spent time managing a backlog and feeling the gap between what you shipped and what actually changed for users.
The most rigorous treatment of flow metrics available. Cycle time, lead time, WIP, and throughput — the metrics that tell you more than burndowns can. Dense but directly practical for anyone managing delivery at scale. Read after you have run at least 20 Sprints.
How to build and maintain systems that stay fast to change over time. The technical side of Agile that most PM-focused courses omit. Understanding deployment pipelines, automated testing, and release cadence makes you a much more effective Product Owner.
The definitive guide to LeSS. Detailed, opinionated, and honest about the trade-offs. Read this before considering any scaling framework — the depth of reasoning about what not to add is as valuable as the framework itself.
Certifications demonstrate commitment and domain knowledge to employers. They vary enormously in rigour and market value. These are the ones most respected in the industry — and the order in which to pursue them.
The most rigorous entry-level Scrum certification. An 80-question online exam with a passing score of 85%. No mandatory training required — study the Scrum Guide and supplementary material. Widely respected by employers. This is the first certification to pursue after the fundamentals course.
The Product Owner equivalent of PSM I. Also exam-only, no mandatory training. Directly relevant if you plan to work as a PO or PM on an Agile team. Pursue this alongside or after PSM I depending on your intended role.
A harder exam focused on facilitation, coaching, and removing systemic impediments. Requires real experience to pass — unlike PSM I, which can be studied for without practice. Pursue after at least six months of active Scrum work.
The most widely held SAFe certification. Requires attending a two-day training course. Most valuable in enterprise environments where SAFe is already in use. Not a priority unless you are working in a large organisation that has adopted the framework.
PSM I if your role or target role is Scrum Master, Agile coach, or delivery lead. PSPO I if your role is Product Owner, Product Manager, or anyone who owns a backlog. Do either of them before SAFe — having a foundation in standard Scrum makes SAFe much easier to understand and much easier to critique when it adds unnecessary complexity.
Work in a real Agile team or run a Sprint on a personal project. The goal is to experience the gap between what the course described and what actually happens. Read "The Lean Startup" during this period. Don't pursue any certification yet.
Study for and sit PSM I or PSPO I. Study the Scrum Guide thoroughly — you will understand it very differently now than you did before the course. Read "User Story Mapping" and "Scrum: The Art of Doing Twice the Work" during this period.
By now you will know whether your primary challenge is execution (cycle time, velocity, Sprint health), product (OKRs, User Journey, backlog management), or organisational (change management, stakeholder communication). Read the books relevant to your actual challenge, not the ones that seem most prestigious.
If your context requires it: explore SAFe, LeSS, flow metrics, or OKRs as a full framework. Consider PSM II or an Agile coaching qualification. At this point the advanced material in this guide will be directly relevant to real situations you have already encountered — which is exactly when it should be read.
One final thought
Agile is a practice, not a credential. The course gave you a vocabulary and a framework. What comes next is built by doing the work, observing what happens, and adjusting. Every Sprint you run, every Retrospective you facilitate, and every backlog you manage teaches you something that no book or certification can. The reading roadmap on this page is here to help you name and understand what you are experiencing — not to replace the experience itself.