BA Academy — self-paced module
By the end of this module, you will be able to:
Module 10 gave you Scrum's complete framework: values, roles, artifacts, and ceremonies. This module zooms all the way in on one role: the Scrum Master: because it is a real career direction for people with exactly your developing skill set. BA-to-Scrum-Master is one of the ecosystem's natural progressions (the facilitation, communication, and process fluency transfer almost one-to-one), and many delivery teams staff a hybrid BA/Scrum Master on smaller projects. Even if you never carry the title, understanding the role deeply makes you a dramatically better teammate to whoever does.
A quick grounding before the deep water: Scrum is an agile project management framework that helps teams structure and manage work through values, principles, and practices. Its three roles: the Scrum Master (helps the team work using agile methods, ensuring everyone, leaders included, communicates and collaborates toward a successful result), the Product Owner (defines user stories, owns and prioritizes the product backlog, and acts as the main link between customer and team), and the Development Team (the group that builds the product from ideation to completion). Its three artifacts: product backlog, sprint backlog, and the potentially releasable product increment. Its four events inside each sprint: sprint planning, daily scrum, sprint review, sprint retrospective. And two details worth pinning from the source material's own knowledge checks: the ideal Scrum team size is about 7 to 9 people (plus or minus 2), and "Project Manager" is not a role defined in the Scrum framework: a favorite interview trick question.
Scrum Masters keep the team's instruments visible and legible.
The burndown chart is the classic: work remaining (usually in story points or tasks) plotted against time across the sprint. An ideal line slopes steadily from total commitment to zero at sprint's end; the actual line tells the story. Flat early segments mean slow starts or blocked work; a line hovering above ideal signals the sprint goal is at risk while there is still time to act: which is the whole point. Burndowns do not manage the team; they give the team an honest mirror.
Sprint dashboards aggregate the wider picture per sprint and per team member: tasks and their states, story points committed versus completed, bugs found and fixed, and summary statistics. Teams use dashboards to track user stories and tasks for each sprint and member: not for surveillance, but for the transparency that lets a self-organizing team actually self-organize. (For a Salesforce BA, these live in the work-tracking tool, and your Module 9 dashboard instincts apply directly.)
Watch the metrics with a coach's eye, not an accountant's: velocity (points completed per sprint) is a planning aid and trends matter more than any single sprint. Metrics that become targets stop being measurements: teams can inflate estimates to look fast. The Scrum Master guards against exactly that misuse.
Two metaphors from the source material carry the essence better than any definition:
Formally: the Scrum Master is the facilitator for the team and the product owner. Rather than managing the team, the Scrum Master works to assist both the Scrum team and the product owner. The distinction is everything: no authority over people, complete ownership of process health. This is leadership without command: influence, credibility, and service (the servant-leader concept from Module 10's Lean values, embodied in a role).
The Scrum Master collaborates with everyone, and the service looks different for each constituency.
The PO owns what; the Scrum Master strengthens how the what gets managed: better-written items, sharper prioritization habits, healthier refinement rhythms.
Notice the verbs: remove, help, coach, facilitate. Never: assign, approve, direct. A Scrum Master who starts assigning tasks has quietly become a project manager and stopped being a Scrum Master.
This third constituency is the one people forget: a Scrum Master's job extends beyond their team to the surrounding organization, whose habits (status-report culture, mid-sprint fire drills, executive drive-bys) determine whether any team's Scrum can survive.
Condensed to the four the source material centers:
What makes someone good at this? The qualities the role demands:
If that list reads like a description of the BA qualities from Module 1 with the volume turned up: yes. That is why this door is open to you.
Theory is easy; Tuesday afternoon is hard. The source material provides four worked scenarios: study the pattern in the answers, because it repeats: protect the sprint, use the framework's own mechanisms, coach rather than command, and keep everyone's dignity intact.
Situation: A product manager goes directly to the development team with an urgent last-minute request: for example, custom code for a large customer.
The move: It is the Scrum Master's responsibility to remind the PM that the team can work only on the tasks agreed to in the current sprint. Interruptions and challenges like this appear constantly during product development. An effective Scrum Master is always there to protect the developers' time and to create an environment where they have a clear path to focus on doing their best work.
Why it works: the response is not "no": it is "not this way." The request has a proper channel (the backlog, the next planning session, or, if truly an emergency, a deliberate conversation with the PO about the cost of breaking the sprint). The team's focus is preserved, and the PM learns the system without being humiliated.
Situation: The team consistently fails to meet its sprint goals.
The move: Facilitate a retrospective to identify the root causes: unclear goals, overcommitment, missing skills, or external disruptions. Once the issues are identified, work with the team to create actionable improvements: refining the backlog, improving estimation techniques, increasing collaboration, or better managing external dependencies. Then support the team in making those adjustments to improve focus and commitment in future sprints.
Why it works: notice what the Scrum Master does not do: lecture the team, extend hours, or quietly reduce scope themselves. The retrospective (the framework's own inspect-and-adapt engine) finds the cause; the team designs the fix; the Scrum Master ensures it actually happens. Root-cause discipline (your 5 Whys from Module 5) belongs here.
Situation: A key stakeholder pressures the Product Owner to deliver a new feature immediately, though it is not prioritized in the current sprint.
The move: Help the PO navigate the pressure by anchoring on the team's commitment to the current sprint and the agreed sprint goal. Work with the PO to explain to the stakeholder the impact of introducing changes mid-sprint and why maintaining focus matters. Optionally, facilitate a direct conversation with the stakeholder about properly prioritizing the feature for future sprints.
Why it works: the Scrum Master serves the PO here, not replaces them: strengthening the PO's hand with process legitimacy and, where useful, facilitating the difficult conversation. The stakeholder's need is honored (it will be prioritized properly), just not at the sprint's expense.
Situation: A stakeholder insists on a feature that is not aligned with current sprint goals, and the team is already committed to current work.
The move: Protect the team from external interruptions and remind the stakeholder of the importance of respecting the current sprint commitment. Suggest the stakeholder bring the request to the next Sprint Planning, where it can be prioritized correctly in the backlog. Support the Product Owner in maintaining focus and in communicating to stakeholders the value of keeping the sprint stable.
Why it works: same principles, firmer application: the sprint boundary is defended, the backlog is offered as the legitimate door, and the PO is backed rather than bypassed. Stakeholders learn that the process is consistent, which, over time, is exactly what earns their trust in it.
Technical debt is the accumulated cost of past shortcuts: work that functions today but will demand payment (rework, slowdowns, fragility) later. The essential distinction:
Why the Scrum Master cares: debt silently eats velocity and morale, and the pressure that creates it (deadline squeezes, mid-sprint scope pushes) is exactly the pressure the Scrum Master manages. Good practice: make intentional debt visible (backlog items, flagged and prioritized with the PO for repayment) and reduce unintentional debt through the Definition of Done, code review norms, and honest retrospectives. Debt that is tracked is a tool; debt that is hidden is a time bomb. Salesforce orgs accumulate exactly the same phenomenon: quick-fix automations and one-off fields (Module 8's Optimizer findings are a debt report), so the concept will follow you everywhere.
Module 10 introduced the Definition of Done: the shared standard a work item must meet to count as complete (built, tested, reviewed, deployed to the agreed environment). In this module's frame, note whose instrument it is: the Scrum Master coaches the team to have an explicit DoD, keeps it visible, and gently refuses the pressure to declare almost-done things done. A weak or ignored DoD is the single fastest generator of unintentional technical debt: unfinished work leaks into the increment and compounds.
A sprint goal is a concise, clear, specific objective the team aims to achieve during the sprint. It provides focus and direction, keeping the team aligned on the most important outcome to deliver by sprint's end. And, per the source material's own quiz: the Product Owner is responsible for defining the sprint goal (in collaboration with the team at planning). The Scrum Master's job is to keep the goal alive all sprint: invoked at standups, defended against drive-bys (Scenarios 1 through 4 above are all, at bottom, sprint-goal defenses), and used as the yardstick at review.
How you slice teams shapes everything about delivery. Two models:
Feature team: a cross-functional, self-organizing team that works on end-to-end features of a product: responsible for delivering a complete feature that provides value to the end user, spanning whatever layers it touches (front end, back end, database).
Component team: organized around specific technical components or layers of the system rather than features: responsible for a particular architectural area (database, API layer, front end, security).
The key differences in one view: feature teams organize around customer value and optimize for speed of user-facing delivery; component teams organize around technical structure and optimize for depth and specialization. Modern agile thinking leans toward feature teams precisely because they are cross-functional and value-focused: but large systems often need some component teams, and the honest answer is usually a mix. For the exam-style checks the source material embeds: the feature team is the more cross-functional; the component team's key drawback is longer delivery cycles for end-to-end features.
Sooner or later, a sprint review goes badly: the increment disappoints, stories are unfinished, stakeholders are visibly unimpressed. The source material provides a complete ten-step recovery process, and it is worth learning as a sequence:
Read the shape of the sequence: steadiness first, evidence second, team-owned improvement third, stakeholder honesty fourth, and institutional learning last. No step is "find who to blame." That absence is the methodology.
The source material closes with a bank of scenario assignments: the practical exam of this module. Work them in writing; in live cohorts we will role-play several. For each, draft your plan before peeking back at the coaching-scenario patterns above.
1. Daily Standup Simulation. The team struggles with time management in the daily standup: some members speak far longer than necessary, delaying everyone and reducing the meeting's effectiveness. Task: create a strategy to keep the standup on track and within its time box. Provide a detailed facilitation plan and an example of how you would run it. (Consider: the three classic questions, a visible timer, "headlines not stories" from Module 20, parking-lot follow-ups for deep dives.)
2. Sprint Retrospective Plan. The last sprint went poorly: multiple blockers, unfinished stories, and demotivated team members. Task: design a retrospective agenda that addresses the team's concerns and improves performance. Outline the activities and techniques you would use to create an open, constructive environment. (Consider: ground rules from Module 17, an anonymous input round for bruised morale, root-cause work, and one or two committed improvement actions rather than ten.)
3. Impediment Removal. A developer is blocked by problems with their development environment and cannot complete tasks on time. Task: what steps do you take to remove the impediment promptly, and how do you work with the team and stakeholders to resolve it? (Consider: triage the blocker's owner, escalate with specifics, arrange interim work, and note the pattern for the retrospective if environments break often.)
4. Conflict Resolution. Two team members conflict over the approach to a technical problem, and it is affecting morale and progress. Task: provide a step-by-step approach to resolving the conflict while maintaining harmony and focus on project goals. (Consider: hear each privately, reframe to shared goals, bring data or a spike/experiment to arbitrate technically, and agree on a decision mechanism: Module 16's influence styles earn their keep here.)
5. Coaching the Product Owner. A new PO struggles to maintain a well-prioritized backlog; requirements are unclear or conflicting, and the team's questions go unanswered. Task: how would you coach the PO on their responsibilities, effective backlog management, and writing clear, actionable user stories with sound prioritization? (Consider: pair on refinement sessions, teach INVEST and story formats from Module 4, install a prioritization framework, and protect the PO's learning curve with stakeholders.)
6. Team Performance Metrics. After several sprints, the team improves in places but still struggles to meet the Definition of Done. Task: identify key metrics to track performance over time, and explain how you would use them to find improvement areas. (Consider: DoD-compliance per story, escaped defects, burndown patterns, velocity trend: used as mirrors for the team, never as weapons.)
7. Promoting Scrum Values. The team resists ceremonies and process, especially under technical workload pressure. Task: how would you reinforce the Scrum values (commitment, courage, focus, openness, respect) with specific actions and behaviors that build a strong, collaborative culture? (Consider: shorten and sharpen the ceremonies rather than defend bloated ones, connect each ceremony to a pain it prevents, and model the values before preaching them.)
8. Managing External Stakeholder Expectations. External stakeholders frequently demand updates, new features, and adjustments misaligned with the current sprint's goals. Task: how do you manage their expectations while keeping the team focused on the sprint backlog, and how do you communicate the value of Scrum's iterative nature? (Consider: a predictable communication cadence they can rely on, sprint reviews as their standing window, the backlog as the always-open door, and the Scenario 3 and 4 playbook.)
Close the loop on why this module lives in a BA course. The overlap is structural: both roles run on facilitation, communication, process discipline, and influence without authority. The differences are real too: the BA owns content (requirements, stories, acceptance criteria: what gets built), while the Scrum Master owns process (how the team works). On small teams one person sometimes wears both hats, and it can work, with one caution: when the same person writes the stories and facilitates the retrospective about why stories were unclear, self-awareness has to work overtime. Know which hat you are wearing, say so out loud, and the hybrid can be the most valuable person on the delivery floor. Module 18 maps where each path leads.
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.