Archive: a 2012 coursework note on Scrum

This entry began as coursework completed while I was a student at Sheridan College Institute of Technology & Advanced Learning.

This 2012 essay explains the Scrum model as I understood it at the time. It is a historical learning note, not a claim that Scrum will solve every delivery problem.

The basic model

Scrum organises work into short, time-boxed iterations called sprints. The original essay described three roles: the Product Owner, Scrum Master, and Development Team. It also described sprint planning, daily scrums, sprint reviews, and retrospectives as the rhythm through which a team selects work, inspects it, and adapts.

The framework can make priorities and work-in-progress more visible. It can also create ceremony without improving a team's decisions when the organisation does not give the team authority, stable goals, or room to act on what it learns.

What I would carry forward

The useful question is not whether a team "does Scrum." It is whether the team can make work, ownership, evidence, and feedback visible enough to change course before a problem becomes expensive.

A regular review and retrospective can help with that. So can a lightweight operating rhythm that fits the system and the people doing the work. The method should serve the decision, not become a substitute for it.