1.Why Salesforce Scrum Mastery is worth getting right
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.
2.How it works in practice
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.
3.Role reality
The framework does not change on Salesforce. The context around it is unusually hostile to a naive reading of it.
| Textbook theory | Delivery reality |
|---|---|
| The Developers are a single, cross-functional group. | Admins build in clicks, developers build in code, and both change what the customer sees. Treat them as two teams and you have already broken Scrum's core rule. |
| The team plans its own release cadence. | Salesforce ships Spring, Summer and Winter releases on its own calendar, whether your Sprint is ready or not. |
| The org belongs to the team. | The org is a shared runtime that other teams and managed packages are actively writing to at the same time as you. |
| The Definition of Done is one list. | It has to be one list that applies equally to a Flow and an Apex trigger, or you have built two-tier delivery without noticing. |
| A quick production fix saves time. | A quick click into production erases the audit trail and normalises the idea that some changes do not need review. |
4.Core delivery pillars
Four places where the SM role earns its keep on a Salesforce team.
A separate Flow board that admins refine alone is not two teams working in parallel, it is one broken team and a guaranteed production incident waiting to happen.
Reserve capacity in the Sprint that lands during preview, park non-critical work behind release-sensitive items, and read the release notes as part of Planning, not after it.
Emergency prod fixes get logged in a shared channel within the hour and a mandatory backport story the next day. The rule survives contact with real emergencies only if the exception is visible.
Fields shipped and Flows activated are vanity. Change failure rate and rework surviving the next seasonal release tell leadership something true.
5.Metrics that survive contact with the org
Generic engineering metrics assume a codebase. Half of a Salesforce team's output is not code.
The one number that reads honestly across both Flow and Apex work.
From ready-for-dev to live, across whichever toolchain the item actually used.
Trending toward zero is the real target, not a one-off good Sprint.
Percentage of shipped items that survive the next seasonal release without rework.
6.Situations you will be asked to handle
The module puts you inside 4 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 12.3: Game: align the Sprint plan to the Salesforce release calendar
- Lesson 12.4: Definition of Done for declarative and code work
- Lesson 12.5: Scenario lab: admins and developers refuse to share a backlog
- Lesson 12.8: Scenario lab: Sprint boundary versus a seasonal release freeze
7.Common mistakes and why they fail
Letting admins and developers run two separate backlogs
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.
Tolerating direct production changes outside the Sprint
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.
Scheduling a Sprint across a seasonal release freeze
Committing to a Sprint Goal that assumes normal deployment cadence during a window when Salesforce's own release freeze restricts what can safely ship.
Applying generic engineering metrics to a mixed platform team
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.
8.Questions worth asking before you commit time to this
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.
9.What to remember
- Why the admin-developer split is the hardest people problem on the platform
- How to plan a Sprint that survives a Salesforce seasonal release
- A situational matrix for the click-in-prod habit and shared Definition of Done
10.Where this sits in the Scrumling course
Coach a mixed admin, developer, and architect team across seasonal releases, governor limits, and the Flow-versus-Apex fault line.
About 60 minutes of lessons and decision scenarios.
- Lesson 12.1: Why Salesforce teams struggle with Scrum
- Lesson 12.2: Admins, developers, and architects in one team
- Lesson 12.6: Coaching the 'we'll just click it in prod' habit
- Lesson 12.7: Change sets, DevOps Center, and unlocked packages
- Lesson 12.9: Metrics that survive contact with the org
- Lesson 12.10: Running retros on a mixed admin and dev team
- Lesson 12.3: Game: align the Sprint plan to the Salesforce release calendar
- Lesson 12.4: Definition of Done for declarative and code work
- Lesson 12.5: Scenario lab: admins and developers refuse to share a backlog
- Lesson 12.8: Scenario lab: Sprint boundary versus a seasonal release freeze
Assessment: Salesforce Scrum Mastery quiz