█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Software Engineering/Agile and Engineering Process/Scrum
35 minBeginner

Scrum

After this lesson, you will be able to: Explain sprints, standups, sprint planning, retrospectives, and the distinct roles of Scrum Master, Product Manager, and Engineer.

Scrum is the most-implemented Agile framework. This lesson covers the ceremonies and roles as they actually work in 2026 product teams.

Prerequisites:What Agile Actually Is

The five Scrum ceremonies

Sprint planning (start of sprint, 1-2 hours): the team commits to a set of stories. Discuss WHAT and HOW. Daily standup (15 min, daily): each engineer answers: what did I do yesterday, what am I doing today, what's blocking me. NOT a status meeting for the manager. Sprint review / demo (end of sprint, 1 hour): the team shows working software to stakeholders. Sprint retrospective (end of sprint, 1 hour): the team reflects on the process. What's working, what's not, what to change next sprint. Backlog refinement (~1 hour mid-sprint): groom upcoming stories so planning goes fast.

Roles: Scrum Master, Product Manager, Engineer

Product Manager: owns WHY and WHAT. Decides which features to build, in what order, for which users. Writes user stories, prioritises the backlog. Scrum Master: owns PROCESS. Removes blockers, facilitates ceremonies, protects the team from outside disruption. Often a team member who wears two hats. Engineer: owns HOW. Estimates work, decides architecture, ships. When roles blur (PM dictating implementation, engineer changing requirements unilaterally) most Scrum dysfunction follows.

Sprint length: 1, 2, or 4 weeks?

1 week: tight feedback loops; planning + retro overhead becomes ~20% of the week. Good for unstable products. 2 weeks: the default. Good balance of feedback and overhead. 4 weeks: more time per ceremony; harder to respond to change. Used by teams with long-cycle work (e.g. embedded). Pick a length and stick with it for at least 6 sprints before changing; otherwise you can't tell what's working.

⚠️ The retro is the most important ceremony

If you only do ONE Scrum ritual, do the retro. It's the only one that improves your process over time. Common format: 'what worked? what didn't? what will we try next sprint?' Pick ONE thing per retro. A retro that produces five action items produces zero changes. One concrete change, tracked, with an owner.

Common mistakes only experienced practitioners avoid

Standups that turn into status meetings for managers. The standup is for the team; managers should listen, not interrogate. Sprint goals that are 'finish the stories on the board'. Real sprint goals describe outcomes, not work units. Estimation theatre: spending an hour debating whether a story is 3 or 5 points. The signal is in the relative size; don't optimise the noise. Retros that surface the same blocker every sprint with no action. Pick something achievable; do it; check next retro. Treating the Scrum Master as a manager. They facilitate, they don't decide.

Quick Check

What's the ONE ceremony you'd protect if leadership cut your meeting time in half?

Pick the most defensible answer.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←What Agile Actually Is vs the Mythology
Back to Agile and Engineering Process
Kanban→