Series: Software Engineering Fundamentals | Part Part 7 of 19 > Delivered at Universidade Potiguar (UnP) in 2010
In the seventh lecture of the Software Engineering course at Universidade Potiguar (UnP), we dove into the operational mechanics of Scrum. Beyond concepts and principles, this class was about understanding how teams work together through specific ceremonies, roles, and artifacts to deliver working software iteratively.
A Cycle That Closes and Begins Again
We began with a metaphor: a spinning wheel — not to dizzy us, but to keep us in rhythm. In Scrum, the Sprint is the unit of progress. It begins with planning, continues through daily alignment, delivers something valuable, and closes with review and reflection.
Each part of the cycle exists to increase visibility, create alignment, and enable learning. Repetition doesn’t mean bureaucracy. It’s a scaffold for momentum — one that builds confidence and capability, iteration after iteration.
The Daily Scrum: Focus and Rhythm
We emphasized the Daily Scrum as a communication ritual — a tuning session before the performance begins. Done right, it prevents duplication and disconnects during the day.
I introduced the classic three-question format and emphasized the importance of timeboxing and consistency. Then we ran a hands-on activity: “Meeting Traps.” Students role-played bad and good meetings. The contrast was striking — and insightful. They quickly realized: meeting isn’t the point — alignment is.
This can be easily replicated in companies. Simulate chaotic vs. productive stand-ups and debrief on the behaviors that undermine communication. It’s a powerful learning tool that turns frustration into awareness.
Sprint Planning: Clarity and Capacity
Using visual models, we mapped out Sprint Planning in two parts: selecting what to do (SPM #1) and how to do it (SPM #2).
We played a hands-on game with tennis balls and backpacks to simulate capacity and velocity. It was fun, a bit chaotic — and unforgettable. We followed it with a Planning Poker exercise, estimating mock features and discussing divergent points of view. Students experienced firsthand how diversity in thought improves effort estimation.
Facilitators can use these same games with teams that struggle to estimate realistically or have trust gaps. It breaks down barriers and builds shared accountability.
Review and Retrospective: Listen, Reflect, Improve
The final segment focused on the Sprint Review (stakeholder-facing, delivery-focused) and the Retrospective (team-facing, process-focused). We used a simple “Keep / Improve” board where students posted sticky notes.
The key insight: Scrum fails without reflection. Repeating cycles without learning is just spinning wheels. Retrospectives don’t need to be rigid, but they must be respected — they are where learning becomes culture.
Simulating a Real Sprint: Planning Game
We closed the session with a full-cycle simulation. Students formed teams, received a fictional backlog, and were tasked with planning, estimating, prioritizing, executing, and reviewing a mini Sprint — all under a ticking clock.
This game is powerful for onboarding new Scrum teams or teaching Scrum to non-technical audiences. It makes abstract roles and events concrete. More importantly, it surfaces the importance of clear roles, thoughtful planning, and constant feedback loops.
Posted as part of the Software Engineering teaching journal. Today we learned that running Scrum is simple — turning it into a value-generating machine takes practice, alignment, and active listening.
Series Navigation
- Introduction: Part 1 - Why Software Engineering?
- Previous: Part 6 - Scrum Productivity
- Current: Part 7 - Scrum Cycle
- Next: Part 8 - XP Quality & Courage
- Complete series: Why Software Engineering? | Taming Complexity | Waterfall Model | Evolutionary Models | Agile Mindset | Scrum Productivity | Scrum Cycle | XP Quality & Courage | XP Principles & Practices | XP in Practice | Domain-Driven Design