Agile and Scrum: what it is, how it connects to the PMBOK, and how the work actually gets done

“Are you agile, or do you work with the PMBOK?” People ask it as if they were two football teams, and they are not. The PMBOK describes what has to happen in any project for it to end well. Agile describes one way of making it happen when the problem cannot be fully planned on day one.

This module covers the side of the seminar that gets misunderstood the most. First, what agile really is: a manifesto of four values and twelve principles, not a tool. Then, how it fits with the five process groups from module 3. And then Scrum in depth, with an example from start to finish, plus Kanban, XP and Lean so you know when each one makes sense.

Where it comes from

In February 2001, seventeen people who had been building software with lightweight methods met in Snowbird, Utah, and signed a short text: the Manifesto for Agile Software Development. They did not invent anything that weekend. Scrum already existed, so did XP, and the idea of small teams working as one unit went back to a 1986 Harvard Business Review article, “The New New Product Development Game”, by Hirotaka Takeuchi and Ikujiro Nonaka, which compared the best product development teams to a rugby team moving the ball forward together.

What the manifesto did was give all of that a common name and say what it shared.

The four values

The manifesto says that, while there is value in the items on the right, the items on the left are valued more:

The sentence almost everyone skips is the manifesto’s last one: “while there is value in the items on the right, we value the items on the left more”. Agile does not say there is no plan, no contract, no documentation. It says which one wins when you have to choose. A team that uses the manifesto as a reason to document nothing is not agile; it is reading half the text.

Outside software, “working software” reads as a result someone can already use: a service already serving people, a process already running, a report already informing a decision.

The twelve principles, grouped

The twelve principles make more sense in four groups than as a list:

Early and continuous value.

1. The highest priority is to satisfy the customer through early and continuous delivery of value.
2. Changing requirements are welcome, even late, and that change is used to the customer’s advantage.
3. Deliver frequently, from a couple of weeks to a couple of months, preferring the shorter timescale.
4. What works is the primary measure of progress.

People and collaboration. 5. Business people and the team work together daily throughout the project. 6. Projects are built around motivated individuals, given the environment, support and trust they need. 7. Face-to-face conversation is the most efficient way of conveying information. 8. The best solutions emerge from self-organizing teams.

Pace and quality. 9. The pace must be sustainable indefinitely for everyone. 10. Continuous attention to technical excellence and good design enhances agility. 11. Simplicity, the art of maximizing the amount of work not done, is essential.

Improvement. 12. At regular intervals the team reflects on how to become more effective and adjusts how it works.

Principle 11 is the most useful outside software and the least applied: the quintessential agile question is not “how do we do this faster” but “which part of this does not need doing at all”.

From manifesto to practice: three layers

A lot of confusion comes from mixing three different things under the word “agile”:

• The mindset is the values and principles. It is not installed; it is practised or it is not.
• Frameworks are minimal rules for living that mindset: Scrum, Kanban, XP, Lean. Each one solves a different problem.
• Practices are standalone tools: a board, a user story, a retrospective. They can be used without a framework and without the mindset.

The most expensive mistake is buying the third layer believing you bought the first: putting a board on the wall and calling Monday’s meeting a “sprint” does not change how decisions get made.

How it connects to the PMBOK

Here is the most debated part, and the short answer is: the process groups do not disappear in an agile project. They repeat, in miniature, inside every Sprint.

In a predictive project they are run once and in order: initiate, plan almost everything, execute, control against the baseline, and close. In an agile project you initiate and close once, but planning, executing and monitoring become a short cycle that repeats every two to four weeks, and each lap plans only what is already known.

Group by group, the mapping looks like this:

What PMI says today

The standard has moved in the same direction. The sixth edition of the PMBOK (2017) was a guide of processes organized in groups and knowledge areas; this seminar is built on it. The seventh (2021) moved to principles and performance domains, and the detail on agile approaches went to the Agile Practice Guide, which PMI produced with the Agile Alliance.

The eighth edition, published in November 2025, brings processes back, presented in a non-prescriptive way. It organizes them in five focus areas that match the same old groups (initiating, planning, executing, monitoring and controlling, and closing) and presents them as applicable to predictive, adaptive and hybrid approaches. In other words, the standard itself stopped treating “PMBOK” and “agile” as mutually exclusive options.

PMBOK is a registered mark of the Project Management Institute, Inc. This material is educational and is not sponsored or endorsed by PMI.

Scrum in depth

The Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last updated in November 2020, defines it in one sentence: “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” The official guide runs to fewer than twenty pages, and that is part of the point: Scrum is deliberately incomplete. It says what has to exist, not how to do each thing.

It rests on three pillars, transparency, inspection and adaptation, and five values: commitment, focus, openness, respect and courage. Everything else (accountabilities, events and artifacts) exists so that those three pillars actually happen.

The three accountabilities

The 2020 guide stopped talking about “roles” and talks about accountabilities. There are three, and together they form a Scrum Team that is typically 10 people or fewer, with no hierarchies or sub-teams inside:

• Product Owner. Accountable for maximizing the value of the product. Owns the Product Backlog: writes the Product Goal, orders what comes first and keeps it visible. It is one person, not a committee. If every manager can reorder the backlog, there is no Product Owner.
• Scrum Master. Accountable for Scrum working as defined: coaches the team, removes impediments and helps the organization understand the framework. Not the team’s boss, and not the daily meeting’s secretary.
• Developers. The people who build the increment, whether they are programmers, analysts, designers or lawyers. They create the Sprint plan, meet the Definition of Done and adjust with each other every day.

In PMBOK terms, the Product Owner absorbs much of what the project manager used to do with scope and stakeholders, and the Scrum Master much of what they did with the team. That is why Scrum has no “project manager” as such, although large organizations often keep one above, coordinating several teams.

The five events

Two details separate real Scrum from the façade:

• The Daily Scrum is not a status report for the boss. It belongs to the Developers and serves the Developers: fifteen minutes to adjust the day’s plan. If someone is taking notes to report upwards, it is no longer a Daily Scrum.
• The Sprint Review is not a presentation. It is a working session with stakeholders where the increment is seen working and the backlog changes are decided.

The three artifacts and their commitments

Each artifact comes with a commitment that gives it meaning:

• Product Backlog → Product Goal. The ordered list of everything the product might need, and the future state it points to.
• Sprint Backlog → Sprint Goal. What was picked for this Sprint, the plan to deliver it, and a single goal that holds it together.
• Increment → Definition of Done. Each concrete step towards the Product Goal. Only what meets the Definition of Done counts as an increment; anything “almost ready” goes back to the Product Backlog.

Product Backlog refinement is not an event; it is an ongoing activity: breaking large items into smaller ones and sharpening them until they can be done within a Sprint.

A complete example

To see how it all fits, a fictional case. A bakery chain with twelve shops wants its business customers (offices, schools, hotels) to place orders without phoning in.

Initiating. The commercial manager becomes Product Owner. The Product Goal: “A business customer can place, pay for and track an order without calling.” A team of six is put together: two developers, a designer, someone from plant operations, someone from accounts receivable, and a Scrum Master. Two-week Sprints.

The initial Product Backlog, ordered by the Product Owner, written as user stories:

Size is relative, not in hours: an 8 costs clearly more than a 5, and a 5 more than a 3. It is for ordering work and knowing how much fits in a Sprint, not for controlling people.

Sprint 1. In Sprint Planning, the team and the Product Owner set the Sprint Goal: “A pilot customer can place a real order for the next day.” To get there they pick stories 1, 2 and 3 (18 points). The Definition of Done they agree on: tested with real data, reviewed by operations and deployed to the pilot environment.

During the Sprint, on day 4 the Daily Scrum finds that the plant cannot receive a file: it needs the order printed by delivery route. Nobody escalates anything to a committee: the team adjusts story 3 within the same Sprint, because the Sprint Goal does not change.

Sprint Review. The pilot customer places a real order in front of the team. Immediate feedback: “I need my boss to approve the order before it goes out.” That was not in the backlog. The Product Owner adds it as a new story and puts it above payment, because without approval no large company will use the tool. That decision is agile in one line: the plan changed because information appeared that did not exist before something working was shown.

Sprint Retrospective. The team notices operations learned about the plant’s format late. Concrete agreement: the plant person reviews every story that touches the plant before it enters a Sprint.

What would have happened in predictive. The team would have gathered requirements for a month, built for three, and shown everything at the end. The boss’s approval would have surfaced in acceptance testing, as a scope change with a cost and a date. Not because the plan was bad, but because that information did not exist until someone used the system.

The other frameworks, and when to use each

Kanban

The Kanban Guide (May 2025 version) defines it as a strategy for optimizing the flow of value through a process. It has three practices: defining and visualizing the workflow, actively managing items in the workflow, and improving the workflow. And four minimum measures: work in progress, throughput (how many items finish per unit of time), work item age (how long it has been open) and cycle time (how long it took from start to finish).

The central rule is to limit work in progress: nothing new starts until there is free capacity. It sounds obvious and it is the hardest thing to sustain, because everyone wants “their” request to start right now.

Scrum or Kanban is not a fight. Many teams use Scrum for the product and Kanban for supporting that same product, and some put a board with limits inside the Sprint.

XP (Extreme Programming)

Put forward by Kent Beck in the late nineties. Where Scrum says little about how to build, XP is very concrete: automated tests written before the code, continuous integration, pair programming, small releases and simple design. It is the framework of the manifesto’s principle 10, technical excellence. Many software Scrum teams borrow their practices from XP.

Lean

It comes from the Toyota Production System and carried over into software and services. Its question is where time is lost between someone asking for something and receiving it: waiting, approvals, rework, work nobody asked for. It underpins Kanban, and is also the natural link to Lean Six Sigma, which gets its own module.

And when there are many teams?

When a product needs several coordinated Scrum teams, scaling frameworks come in: SAFe, LeSS, Disciplined Agile and others. They are useful in large organizations, but with a warning: scaling a framework does not fix teams that do not yet work on their own. First one team that delivers every Sprint; then coordination across several.

Where agile is not the answer

Agile helps when the problem is discovering what to build. It does not help as much when:

• The scope is set by a regulation or a third party. A licensed construction job, a regulatory change with a fixed date and text, a fixed-price contract with closed deliverables. You can work in increments, but scope is not negotiated Sprint by Sprint.
• Change is very expensive once done. Pouring a structure, a print run, deploying to hardware that cannot be updated. The cost of getting it wrong justifies more planning up front.
• Nobody decides. Without a Product Owner with real authority, the backlog becomes everyone’s wish list and the Sprints an order queue.
• Nobody can give the team their time. An agile team needs to be dedicated. People split across five projects do not run Sprints; they run interruptions.

That is why module 2 ends where it does: in serious projects the answer is almost always hybrid. The regulatory front gets planned in full; the front the user has to discover gets worked in Sprints.

The mistakes that turn Scrum into a façade

• Daily Scrum as a status report. If the team talks to the boss and not to each other, it is a progress meeting with another name.
• A Product Owner without authority. If every priority has to go through a committee, the Product Owner is a messenger.
• Sprints without an increment. If at the end of a Sprint there is nothing that can be used or shown, there were two weeks of work, not a Sprint.
• Velocity as a target. Points help the team plan. Using them to compare teams or reward people inflates them until they are useless.
• Skipping the retrospective when things are rushed. That is exactly when it is needed most.
• Changing the Sprint Goal halfway. The Sprint’s scope can be adjusted; if the goal stops making sense, the right move is to cancel the Sprint, not quietly change its target.

The module challenge

Take a real project, yours or your company’s, and write:

1. The Product Goal in one sentence.
2. The first ten user stories, in order.
3. The first Sprint Goal and which stories go in.
4. The Definition of Done.

If you cannot write the Product Goal in one sentence, that is the finding: the problem is not the method, it is that what you want to achieve is not clear yet.

Where to go next

This module closes the life cycles and methods part of the seminar. The earlier ones:

• How a project is born, module 1: from idea to approved business case.
• How to choose a project life cycle, module 2: predictive, iterative, incremental, agile and hybrid.
• The five process groups and where AI fits in, module 3.

And if you want to see how Scrum connects with strategy, OKRs and KPIs: one leads, the other reports covers the layer above: the OKR sets the quarter’s impact and Scrum delivers it in Sprints.

A note on how this was written

The structure and examples come from twenty years of professional experience, more than fifteen in the financial sector, and from the Project Management seminar. The writing was done with the help of an AI tool. Scrum’s definitions, durations and rules were checked against the 2020 Scrum Guide; Kanban’s, against the May 2025 version of its guide; and the description of the PMBOK editions, against PMI’s page. The bakery chain case is fictional, as are the boards and the burndown chart.

Sources

• Manifesto for Agile Software Development — Beck, K. et al. (2001)
• Principles behind the Agile Manifesto
• The Scrum Guide, November 2020 — Ken Schwaber and Jeff Sutherland, CC BY-SA 4.0 licence
• The Kanban Guide, May 2025 version — Orderly Disruption Limited and Daniel S. Vacanti, Inc.
• PMBOK Guide, 8th edition (November 2025) — Project Management Institute
• Agile Practice Guide — Project Management Institute and Agile Alliance
• PMBOK Guide, 6th edition (2017) — Project Management Institute
• “The New New Product Development Game” — Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986
• Extreme Programming Explained: Embrace Change — Kent Beck, Addison-Wesley (1999)