What Salesforce Scrum Mastery trains
A Salesforce delivery team is rarely a uniform group of Developers in the Scrum Guide sense, it is usually a mix of admins, developers, and architects with different tools, different risk tolerances, and sometimes different reporting lines, and this module opens by naming why that combination makes standard Scrum coaching insufficient on its own. Early lessons cover aligning the Sprint plan to the Salesforce release calendar in a dedicated game, since a Sprint that ignores an upcoming seasonal release is planning against a moving platform, and building a Definition of Done that actually covers both declarative and code work without treating one as more rigorous than the other by default.
A recurring coaching challenge gets its own scenario: admins and developers who refuse to share a single backlog, often because their tools and workflows genuinely differ, Flow builder versus a code editor, but the module argues this split quietly recreates two separate teams inside one Scrum Team, which breaks the no-sub-teams rule at the center of Scrum. A second, very platform-specific anti-pattern gets direct attention: the habit of clicking a fix directly into production because it feels faster than going through the Sprint, and the module gives concrete coaching language for why that habit erodes the Definition of Done even when the individual fix was harmless.
The middle of the module covers the mechanics that make a mixed team's work traceable and safe: change sets, DevOps Center, and unlocked packages as the actual toolchain choices available for moving Salesforce work through environments, and a scenario where a Sprint boundary collides directly with a seasonal release freeze, a very real scheduling conflict that a Scrum Master has to navigate without simply ignoring either constraint.
The module closes on metrics that survive contact with a live Salesforce org, since generic engineering metrics often assume a codebase that does not include declarative configuration, and running retrospectives on a team that includes admins, developers, and architects who may not naturally see themselves as peers. The goal throughout is a Scrum Master who treats the platform's constraints as real inputs to facilitation, not as an excuse to abandon Scrum's core rules about one backlog and one team.
Mistakes teams make with this material
Splitting configuration work and code work into parallel tracks with separate planning. This recreates sub-teams inside a Scrum Team, which breaks the framework's core rule against internal hierarchy or division.
Allowing quick fixes to be clicked directly into a live org because raising them through the Sprint feels slower. Each one bypasses the Definition of Done and makes the org's real state untraceable.
Committing to a Sprint Goal that assumes normal deployment cadence during a window when Salesforce's own release freeze restricts what can safely ship.
Measuring the team purely on code-centric metrics that ignore the declarative configuration half of the work, which undercounts a large share of what admins actually deliver.
Questions people ask
How do you get admins and developers onto one shared backlog?
Anchor both to the same Sprint Goal and Definition of Done, and make refinement a joint activity where declarative and code solutions are compared side by side for the same problem, rather than assigning admin work and developer work to separate parallel processes.
Why is clicking a fix directly into production a problem if it works?
It bypasses the Definition of Done, leaves no traceable record in the Sprint Backlog, and normalizes the idea that some changes do not need review. Even a harmless individual fix erodes the discipline the rest of the team's changes rely on.
What should a Scrum Master do when a Sprint boundary collides with a release freeze?
Adjust the Sprint plan around the freeze window explicitly rather than ignoring it, treating the freeze as a known constraint the same way a public holiday or planned outage would be factored into capacity.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Admins and developers on the same Salesforce team refuse to share a backlog. What is the SM's strongest first move?
- Confront the loudest developers publicly in Retro
- Coach the loudest voices privately with concrete evidence, then facilitate the team to own a single backlog and a single Definition of Done
- Split into two teams so each faction can run its own board
- Escalate to the engineering director
Two backlogs on one org is one broken team and one guaranteed production incident. Feedback in private, norms in public.