Skip to content

Project Management Leadership with AI · Agile, Scrum, Kanban and hybrid delivery · lesson 12 of 21 · 15 min

Scrum essentials

What Scrum is

Scrum is a lightweight framework for developing complex products through short, fixed-length iterations called Sprints. It is defined in the Scrum Guide (the 2020 edition is the current version at the time of writing). Scrum is built on empiricism (transparency, inspection, adaptation) and lean thinking (focus on essentials, reduce waste).

Accountabilities

The Scrum Team has three accountabilities:

| Accountability | Core responsibilities | |---|---| | Product Owner | Maximising the value of the product; managing the Product Backlog (ordering, clarity, Product Goal) | | Scrum Master | Establishing Scrum as defined; coaching the team and organisation; removing impediments; improving effectiveness | | Developers | Creating a usable Increment each Sprint; planning the Sprint Backlog; adhering to the Definition of Done |

"Developers" means everyone doing the work (designers, testers, analysts, engineers), not only programmers. The Scrum Guide describes teams as typically small, 10 or fewer people.

Events

| Event | Purpose | Maximum timebox (for a one-month Sprint) | |---|---|---| | Sprint | Container for all work; fixed length, one month or less | — | | Sprint Planning | Why (Sprint Goal), what (selected items), how (plan) | 8 hours | | Daily Scrum | Developers inspect progress toward the Sprint Goal and adapt | 15 minutes | | Sprint Review | Inspect the Increment with stakeholders; adapt the Product Backlog | 4 hours | | Sprint Retrospective | Inspect how the team worked; plan improvements | 3 hours |

For shorter Sprints, events are usually shorter.

Artifacts and commitments

| Artifact | Commitment | Meaning | |---|---|---| | Product Backlog | Product Goal | The long-term objective for the product | | Sprint Backlog | Sprint Goal | The single objective for the Sprint | | Increment | Definition of Done | The quality standard every Increment meets |

Backlog refinement

Refinement is the ongoing activity of breaking down and clarifying backlog items so they are ready for future Sprints. Good items follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Many teams spend a modest share of their capacity on refinement; the Scrum Guide does not prescribe an amount.

Worked example: a Sprint in practice

Illustrative. A fictional edtech startup in Karachi runs two-week Sprints.

  • Sprint Planning: Product Goal: "Students can complete a full practice exam on mobile." Sprint Goal: "A student can start, save and resume a timed practice test." The Developers select 8 backlog items and plan tasks.
  • Daily Scrum: 15 minutes each morning; a blocker on the timer component is resolved by pairing.
  • Sprint Review: Demo to a group of teachers; feedback leads to two new backlog items (accessibility of the timer; offline mode) that the Product Owner orders.
  • Retrospective: The team notices testing is squeezed at the end; they agree to pair testers with developers from day one.

Anti-patterns to avoid

  • Product Owner as a proxy with no decision authority.
  • Scrum Master acting as a task manager or status reporter.
  • Daily Scrum turned into a status report to a manager.
  • Sprint Goals missing, so Sprints become lists of unrelated tasks.
  • "Done" that excludes testing ("done but not tested").
  • Sprint length changed frequently to fit work.
  • Velocity used to compare teams or as a performance target.

Scrum and the project manager

Scrum does not define a project manager role. In organisations that use Scrum within projects, PM responsibilities are often distributed: the Product Owner handles scope and priorities, the Scrum Master handles process and impediments, and a project or delivery manager may handle cross-team coordination, budget, governance, vendor contracts and reporting. Clarify these boundaries to avoid conflict.

Common mistakes

  • Adopting ceremonies without empiricism ("mechanical Scrum").
  • Ignoring the Definition of Done under deadline pressure.
  • No real stakeholder feedback at Sprint Reviews.
  • Retrospectives with no follow-through on actions.

Quick self-check

Can every team member state the current Sprint Goal and the Product Goal? If not, the team may be busy without being focused.

Starting with Scrum

If your team is new to Scrum, start with the full framework as described rather than picking selected events; the parts reinforce each other. Choose a sprint length (two weeks is common), agree a Definition of Done, create an ordered Product Backlog with a Product Goal, and run all events for several sprints before adapting. Use retrospectives to improve how you apply Scrum, not to drop the parts that feel uncomfortable.

Hands-on: a Scrum health checklist (score 0/1 each)

Accountabilities
[ ] One Product Owner who orders the Product Backlog and can say no
[ ] Scrum Master coaches and removes impediments; does not assign tasks
[ ] Developers plan their own work and own the Definition of Done
Events
[ ] Every Sprint has a one-sentence Sprint Goal the Developers can state
[ ] Daily Scrum ≤ 15 minutes, run by and for the Developers, focused on the Sprint Goal
[ ] Sprint Review inspects a working Increment with real stakeholders; the backlog changes as a result
[ ] Retrospective produces at least one improvement that is done in the next Sprint
[ ] Sprint length is fixed; Sprints are not extended to finish work
Artifacts and commitments
[ ] Product Goal exists and is visible
[ ] Sprint Backlog is visible and updated daily
[ ] Definition of Done applied to every item; undone work does not count
[ ] Refinement happens regularly; top backlog items are ready
Score = ___ / 12   → pick the two weakest items to improve next Sprint

Hands-on: velocity and a simple release forecast (Python)

import statistics as st

velocity = [21, 18, 24, 20, 23, 19]        # story points per Sprint (illustrative)
remaining = 160
low, mid, high = min(velocity), st.median(velocity), max(velocity)
print(f"Sprints remaining: likely {remaining / mid:.1f}, range {remaining / high:.1f}–{remaining / low:.1f}")

Use velocity only for the team's own forecasting; comparing velocity across teams, or using it as a performance target, distorts estimates.

Prompt template: drafting a Sprint Goal (approved AI tool)

Here are the top backlog items and the Product Goal. Propose three alternative one-sentence Sprint Goals that describe
a user-visible outcome, not a list of tickets. For each, say which items it needs and which could be dropped if
the Sprint gets tight. The team chooses; do not decide for them.

How to measure success

  • Health checklist score rising Sprint on Sprint.
  • Sprint Goals met in most Sprints, with scope flexed rather than the Definition of Done.
  • Stakeholder feedback from Reviews visibly changing the backlog.

Video lecture: Scrum essentials

Lecture coming soon · 9 chapters · about 8 minutes. Read the full transcript below.

  1. A small framework with big consequences
  2. Why it matters
  3. The concept: accountabilities
  4. Events and artifacts
  5. Worked example one: a good Sprint Goal
  6. Worked example two: a Karachi edtech Sprint
  7. Watch me do it: a quick Scrum health check
  8. Refinement, anti-patterns and the project manager
  9. Recap and try this now

Lecture transcript

A small framework with big consequences

Scrum is deliberately small. The official Scrum Guide, in its twenty twenty edition which is still current, is only a handful of pages. And yet teams get it wrong in remarkably consistent ways: daily stand-ups that become status reports to a manager, sprints with no real goal, reviews that are slide shows rather than inspections of working product. In this lecture you'll learn the essentials of Scrum as the Scrum Guide defines it: the three accountabilities, the five events and their purposes, the three artifacts and the commitments that make them useful, and how backlog refinement keeps it all flowing. Then we'll look at the common anti-patterns and where a project manager fits. By the end, you'll be able to observe a Sprint and tell whether it's genuinely Scrum or just meetings with Scrum names.

Why it matters

Why does Scrum matter? Because it's built around short feedback loops. Every sprint ends with a usable increment that real stakeholders inspect. So if you've misunderstood what users need, you find out in two weeks, not at the end of a year-long build. Scrum rests on three pillars: transparency, so everyone can see the real state of the work; inspection, looking at that work frequently; and adaptation, changing course based on what you learn. When those pillars are present, Scrum is powerful. When they're missing, Scrum becomes a set of extra meetings, and teams understandably conclude that agile doesn't work. The difference is almost always in the details we're about to cover.

The concept: accountabilities

The Scrum Guide defines three accountabilities. The Product Owner is accountable for maximising the value of the product, which in practice means managing and ordering the Product Backlog and setting the Product Goal. One person, not a committee. The Scrum Master is accountable for establishing Scrum as the Guide defines it, coaching the team and the organisation, and helping remove impediments. And the Developers, which means everyone doing the work, designers, testers, analysts and engineers, not just programmers, are accountable for creating a usable Increment each Sprint, planning the Sprint Backlog and meeting the Definition of Done. The team is small, typically ten or fewer people. Think of a football team: the manager picks the strategy, the coach improves how they play, and the players decide the moves on the pitch.

Events and artifacts

Now the events. The Sprint itself is a fixed-length container, one month or less, for all the work. Sprint Planning decides why this Sprint is valuable, the Sprint Goal, what can be done, and how. The Daily Scrum is a fifteen-minute event for the Developers to inspect progress towards the Sprint Goal and adapt their plan. It's not a status report to a manager. The Sprint Review inspects the Increment with stakeholders and adapts the Product Backlog. And the Sprint Retrospective looks at how the team worked and plans improvements. Then the three artifacts, each with a commitment. The Product Backlog, committed to the Product Goal. The Sprint Backlog, committed to the Sprint Goal. And the Increment, committed to the Definition of Done. Here's the key idea: the commitments are what make the artifacts meaningful. Without a Sprint Goal, a Sprint is just a to-do list with a deadline.

Worked example one: a good Sprint Goal

Let's look at Sprint Goals, because they're the most commonly skipped element. A weak goal: 'complete tickets one oh one to one oh eight'. That's just a list. If one ticket turns out harder than expected, the team has nothing to guide a trade-off. A strong goal: 'a student can start, save and resume a timed practice test'. Now the team knows why this Sprint matters. If the timer component turns out to be tricky, they can simplify the styling ticket to protect the goal, or swap in a different approach, and still deliver something coherent and valuable. The goal gives focus and it gives room to adapt. When I observe a team, the first thing I ask any developer is: what's your Sprint Goal? If they can't tell me in one sentence, the Sprint is probably a list.

Worked example two: a Karachi edtech Sprint

Now the example from the lesson. A fictional edtech start-up in Karachi runs two-week Sprints. The Product Goal: students can complete a full practice exam on mobile. In Sprint Planning, the Sprint Goal becomes: a student can start, save and resume a timed practice test, and the Developers select eight backlog items and plan their tasks. At the Daily Scrum, a blocker on the timer component is resolved by pairing two developers. At the Sprint Review, the team demonstrates the working feature to a group of teachers, whose feedback leads to two new backlog items, accessibility of the timer and offline mode, which the Product Owner orders. At the Retrospective, the team notices testing gets squeezed at the end, so they agree that testers will pair with developers from day one. Every event did its job.

Watch me do it: a quick Scrum health check

Let me show you how I assess whether a team is really doing Scrum. I observe one full Sprint and score a simple checklist. Accountabilities: is there one Product Owner who actually orders the backlog? Does the Scrum Master coach rather than assign work? Events: is there a Sprint Goal? Is the Daily Scrum run by and for the Developers, about the goal rather than individual status? Does the Review inspect a working Increment with real stakeholders, and does the backlog change as a result? Does the Retrospective produce an improvement that's actually implemented next Sprint? Artifacts: is there a Product Goal? Is the Definition of Done applied to every item? I score it, and then I pick just the two weakest items to work on. Trying to fix everything at once rarely works.

Refinement, anti-patterns and the project manager

Backlog refinement is the ongoing work of breaking down and clarifying backlog items so they're ready for a future Sprint: small enough, clear enough, with testable acceptance criteria. Protect it; when it's cancelled, quality usually suffers, as we saw in the quality lecture. Common anti-patterns: a proxy Product Owner with no real authority; Daily Scrums that are status reports to a manager; Sprint Reviews that are slide presentations; Retrospectives that never produce a change; and Sprints extended to finish the work. So where does a project manager fit? Scrum doesn't define a project manager accountability, but many organisations need someone to handle governance, stakeholders outside the team, cross-team dependencies, budgets, contracts and risks. A good project manager supports the Scrum Team and connects it to the organisation, without undermining the Product Owner or directing the Developers' daily work.

Recap and try this now

Let's recap. Scrum, as the twenty twenty Scrum Guide defines it, has three accountabilities: Product Owner, Scrum Master and Developers. Five events: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. And three artifacts, each with a commitment: the Product Backlog and the Product Goal, the Sprint Backlog and the Sprint Goal, and the Increment and the Definition of Done. It works when transparency, inspection and adaptation are real, and it fails when events become ceremonies without purpose. Your try-this-now: observe, or imagine, one full Sprint for a team you know, score it against the health checklist in the lesson, and pick the two weakest items to improve.

Key takeaways

  • Scrum is an empirical framework with three accountabilities: Product Owner, Scrum Master and Developers.
  • Five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
  • Three artifacts with commitments: Product Backlog/Product Goal, Sprint Backlog/Sprint Goal, Increment/Definition of Done.
  • Avoid anti-patterns such as proxy Product Owners, status-report stand-ups and velocity as a target.

Try it

Observe (or imagine) one full Sprint for a team you know and list which Scrum events, artifacts and commitments are working well and which are missing.