What the Developer campaign trains
The Developer campaign treats Scrum as an engineering discipline problem, not just a process to follow. It opens with your role as a Developer inside the Scrum Team, then immediately puts you into a Sprint Planning game where you have to size a Sprint Backlog against real capacity instead of optimism. The lessons that follow, the anatomy of a Sprint Backlog and building a Definition of Done that actually holds the line, exist to answer the question every Developer eventually faces under pressure: what happens when finishing everything on the plan would mean quietly skipping the tests.
A dedicated game, Is it really Done?, forces you to apply the Definition of Done to ambiguous, half-finished work rather than recite it as policy. This connects to a broader theme running through the whole campaign: self-management is not the absence of standards, it is the team enforcing its own standards without being told to. Lessons on what self-management actually looks like and why technical excellence is a Scrum concern, not a separate engineering-culture issue, make the case that a Scrum Team without craftsmanship is not more agile, it is just accumulating debt faster.
The middle of the campaign gets concrete: pairing and mobbing as deliberate Sprint tools rather than a fallback for onboarding, refactoring as something that happens inside the Sprint rather than in a mythical future cleanup phase, and estimation handled lightly enough that it informs planning without becoming a second full-time job. A checkpoint on planning to capacity and one on Is it really Done? reinforce both skills before the campaign moves into your job in the Daily Scrum, specifically what a Developer should be inspecting and adapting day to day, separate from a status update to the Scrum Master.
The final third covers code review as a team habit rather than a gate one person owns, a mid-Sprint replanning checkpoint for when reality diverges from the plan, building an actual test strategy for a Sprinting team, and managing technical debt honestly instead of pretending it does not exist or letting it silently take over every Sprint. The campaign closes on shipping the smallest useful thing, the practical antidote to both over-engineering and half-finished increments.
Mistakes teams make with this material
Quietly skipping tests, code review, or documentation to hit a Sprint commitment. The Definition of Done exists precisely for moments like this; bending it under pressure is how technical debt becomes invisible until it is expensive.
Pulling in work based on what the team hopes to finish rather than what its actual, historically demonstrated capacity supports. This produces a Sprint Backlog that looks good in planning and fails by day three.
Deferring all technical debt work to some future Sprint that never arrives because new feature pressure always wins the argument. Refactoring that supports the current Sprint Goal belongs inside the Sprint, not in a backlog graveyard.
Turning the event into three bullet points delivered to the Scrum Master instead of a real conversation among Developers about the plan for reaching the Sprint Goal. That kills the actual value of the event.
Questions people ask
Who decides the Definition of Done?
The Developers own the Definition of Done, though it must meet or exceed any organizational standard already in place. It is not handed down by a manager or negotiated away by the Product Owner under deadline pressure; it is the team's own quality bar.
How much estimation is actually necessary?
Enough to support a useful forecast and nothing more. The module treats estimation as a lightweight input to planning conversations, not a precise science, and warns against spending more time estimating than the estimate itself is worth.
Is technical debt always bad?
No. Deliberate, tracked technical debt taken on to hit a real deadline can be a sound trade. The failure mode is undisclosed debt that nobody decided to take on and nobody is paying down, which is what the module's lesson on managing debt honestly is built to prevent.