Agile and Scrum: Roles, Events and Artifacts

Agile is a way of delivering work in small, usable pieces and adjusting based on feedback, instead of planning everything up front and delivering once at the end. Scrum is the most widely used agile framework: a small, self-managing team works in fixed-length cycles called sprints, each producing a usable increment of the product. This lesson explains how Scrum works according to the official Scrum Guide, and shows a Denver app team using it to forecast its launch.

1. Agile values
2. Scrum team
3. Scrum events
4. Artifacts
5. Forecast with velocity

Agile in one page

In 2001, a group of software practitioners wrote the Manifesto for Agile Software Development: four values and twelve principles. The four values are short enough to quote in full:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The manifesto itself points out that the items on the right still have value; the items on the left are valued more. Agile doesn't mean "no plan" or "no documentation." It means planning in smaller slices and letting real feedback reshape the plan. As you saw in the first lesson, it shines when requirements are uncertain and changes are cheap, which is why software and digital products adopted it first.

Scrum: the official source

Scrum is defined by the Scrum Guide, written by Scrum's co-creators Ken Schwaber and Jeff Sutherland. The current version is the November 2020 edition. In June 2025, Jeff Sutherland and collaborators published a "Scrum Guide Expansion Pack," but it's an optional supplement, not a new version: the 2020 guide is still the reference. Everything below follows it. Practices like user stories, story points and velocity are popular additions to Scrum, not part of the guide.

The Scrum team: three accountabilities

At Front Range Fitness, the Denver gym chain building a member app (you met its budget in the cost lesson), the marketing director is the Product Owner, an agile coach from the agency is the Scrum Master, and two mobile developers, a designer and a tester are the Developers. Where's the project manager? In many organizations the PM role overlaps with these accountabilities or works at the program level: managing the budget, vendors, the launch date and stakeholders outside the team.

The five events

Scrum uses fixed-length events, each with a maximum duration (a timebox). The timeboxes below are the Scrum Guide's limits for a one-month sprint; for shorter sprints the events are usually shorter.

1. One month or lessThe SprintThe container for all other events. A new sprint starts immediately after the previous one ends. Front Range Fitness uses two-week sprints.
2. Day 1 · up to 8 hoursSprint PlanningThe team answers three questions: why is this sprint valuable (the Sprint Goal)? What can be done? How will it get done?
3. Every day · 15 minutesDaily ScrumThe Developers inspect progress toward the Sprint Goal and adapt their plan for the next day. It's not a status report to a manager.
4. Last day · up to 4 hoursSprint ReviewThe team shows the increment to stakeholders, discusses what changed and updates the Product Backlog. A working session, not a slideshow.
5. Last day · up to 3 hoursSprint RetrospectiveThe team discusses how the sprint went (people, process, tools) and picks improvements for the next sprint.

Three artifacts and their commitments

Each Scrum artifact comes with a commitment that gives it focus:

The Definition of Done is the quality bar that every increment must meet. Without one, "done" means different things to different people, and unfinished work piles up quietly until launch week.

Tracking a sprint: the burndown chart

Many teams estimate backlog items in story points, a relative measure of size and complexity, and track the points still remaining each day. In sprint 5, the team committed to 24 points:

A burndown that's flat for days is a conversation starter at the Daily Scrum: what's blocking us, and should we renegotiate scope with the Product Owner while there's still time?

Forecasting a release with velocity

Velocity is the number of points a team completes per sprint. It's useful for forecasting, and only for that team: comparing velocities between teams is meaningless, because each team sizes points differently. Here are the team's first four sprints:

Sprint 1 is usually slow (setting up tools, learning the domain), so the team averages the last three sprints. With 168 points left in the Product Backlog for launch:

Average velocity (last 3) = (22 + 27 + 23) ÷ 3 = 24 points
Sprints needed            = 168 ÷ 24 = 7 sprints → 14 weeks

Best case:  168 ÷ 27 = 6.2 → 7 sprints (14 weeks)
Worst case: 168 ÷ 22 = 7.6 → 8 sprints (16 weeks)

The honest forecast is "7 to 8 sprints, 14 to 16 weeks," not a single date. And the forecast only holds if the backlog doesn't grow, which it usually does. Re-forecast after every sprint.

Common Scrum mistakes

(a) Average velocity = (27 + 30 + 33) ÷ 3 = 30 points
    255 ÷ 30 = 8.5 → 9 sprints → 18 weeks
(b) Best case:  255 ÷ 33 = 7.7 → 8 sprints (16 weeks)
    Worst case: 255 ÷ 27 = 9.4 → 10 sprints (20 weeks)

Summary

• Agile delivers in small increments and adapts to feedback; it doesn't mean "no plan."
• The 2020 Scrum Guide is the official reference; the 2025 Expansion Pack is an optional supplement.
• Scrum has three accountabilities (Product Owner, Scrum Master, Developers), five events and three artifacts.
• Commitments give focus: Product Goal, Sprint Goal and Definition of Done.
• Forecast with the team's own velocity, as a range, and re-forecast every sprint.

Next lesson: Kanban: Boards, WIP Limits and Flow Metrics. You'll design a Kanban board, set WIP limits and use Little's Law to cut waiting time.