Agile & Scrum for BAs

Why Agile Matters to You

Module 1 told you that BAs coordinate with the Project Manager on running Scrum ceremonies: daily huddles, backlog grooming, retrospectives. Modules 3 and 4 taught you to produce the fuel agile teams burn: user stories with acceptance criteria. This module gives you the framework those pieces live inside. Nearly every Salesforce consulting team works in some flavor of Agile, and interviewers will probe your fluency in it. By the end of this module that fluency is yours.

Waterfall and Agile: Plan Versus Adapt

Waterfall is the traditional approach: everything is planned up front, requirements are collected in detail before implementation, each step must be completed before the next begins, and the outcome is determined at the beginning. Waterfall is not wrong; it is right for work whose outcome is fully known in advance.

Agile is built for the other kind of work: innovation-based and iterative, where the final outcome is not fully known and the path is a work in progress.

A painting metaphor makes the difference vivid. If you decide your colors, your setting, your time budget, and your final image before touching the canvas, you have left no room for changes along the way: that is waterfall, and the picture might still be excellent, but the process cannot incorporate new ideas or feedback. Painting iteratively (sketch, step back, adjust, layer) expects change based on early feedback and new learnings ("those colors clash!"). That is Agile.

The honest selection rule: choose by work complexity, by what you know and do not know at the start. Even Salesforce, the company, runs some teams on waterfall. Most Salesforce consulting work, though, is squarely in Agile territory: clients discover what they really need as they see working software, which is the exact situation Agile was invented for.

The Agile Manifesto

In 2001, seventeen software engineers, exhausted by large, expensive, document-heavy, design-it-all-up-front projects that kept failing, drafted the Agile Manifesto. Its four values:

We value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Read the last line twice: Agile does not abolish process, documentation, contracts, or plans. It ranks them below people, working results, collaboration, and adaptability when the two collide.

What the values mean in practice: teams dictate their own workflow rather than having legacy process dictate it; progress is validated by a tangible working result, not by a specification document (a spec, by itself, proves nothing works and delivers no customer value); customers tell you what is best for them rather than you assuming it; and short cycles plus continuous feedback make change an advantage instead of a catastrophe.

The manifesto's twelve principles flesh out the values. In condensed form: satisfy the customer through early and continuous delivery of valuable software; welcome changing requirements, even late; deliver working software frequently, preferring shorter timescales; business people and developers work together daily; build projects around motivated individuals, give them environment, support, and trust; face-to-face conversation is the most effective communication; working software is the primary measure of progress; maintain a sustainable pace indefinitely; attend continuously to technical excellence; maximize simplicity (the art of work not done); trust self-organizing teams; and reflect regularly on how to become more effective, then adjust.

Doing Agile Versus Being Agile

There is a difference between doing agile (following the ceremonies) and being agile (knowing why). The three-question self-test: Do our activities focus on people? Are we continuously learning and improving to evolve our process and product? Are we frequently delivering value and delight to our customer? Three yeses and you are on your way. Ceremonies without the mindset are just meetings.

Agile Beyond Software

Agile's values apply to any complex project, not just code. The source material's example: an office redesign run in iterative cycles: gather input, produce a partial layout, collect feedback, adjust, repeat, instead of unveiling a finished floor plan to horrified employees at the end. Project approaches are like recipes: experience, preferences, and circumstances drive the choice, and the same "dish" (a delivered project) has many valid recipes. As a BA you will meet Agile applied to training rollouts, change programs, and process redesigns: the iterate-and-learn loop transfers.

Scrum

Scrum is the most popular Agile framework, and Salesforce itself adopted it in 2006 when growth made its release trains grind: roughly 70 percent of its teams still run Scrum. Scrum is a workflow where roles, meetings, and deliverables are well-defined, and the process allows teams to continuously test and improve both product and process.

Scrum's key traits: it provides a framework to deliver high-quality value to customers faster; everyone is organized into small, cross-functional teams; and teams work in short iterations called sprints (two weeks is the common cadence).

The Five Scrum Values

1. Focus. Teams collaborate on everything, finish a task together, then move to the next; clear priorities and a shared sprint plan keep everyone accountable to the outcome rather than to individual progress.
2. Courage. Innovation requires risk. Teams are transparent about progress, speak up when they need help, and report back when assumptions were wrong. Tackling projects together gives everyone more courage than facing challenges alone.
3. Openness. Consistently verbalize how you are doing, flag obstacles before they linger, be honest about timing and planning. Openness prevents unwanted surprises and last-minute fire drills, and includes admitting mistakes with the intent to improve.
4. Commitment. Commitment is to the process and the team, not a blood oath to deliver a fixed scope by a fixed milestone. Teams in control of their process are in control of their outcomes.
5. Respect. Cross-functional teams only work when every discipline's contribution is valued.

Scrum Roles

The classic Scrum framework defines three roles:

• Product Owner: owns the product backlog and its prioritization; the voice of business value. Decides what gets built and in what order.
• Scrum Master (sometimes Scrum Lead): owns the process; facilitates ceremonies, removes impediments, coaches the team, and shields it from disruption. Decides nothing about what: guards how. (Module 22 is an entire deep dive into this role, including its coaching craft.)
• Development Team: the cross-functional group that builds the increment: developers, admins, QA, and yes, frequently the BA.

Larger organizations add supporting roles around this core: subject matter experts consulted for specialized knowledge, technical program managers coordinating across teams, and functional managers supporting people's growth. Titles vary; the three-role core is what endures.

Where does the BA sit? Most commonly inside the development team, owning requirements clarity, and partnering closely with the Product Owner (in some engagements the BA effectively is the proxy Product Owner for the client). The section at the end of this module maps your ceremony-by-ceremony duties.

The Artifacts: Backlogs and the Increment

Product Backlog. The ordered list of everything that could be needed in the product: the single source of truth for all changes, updates, and requirements the team believes necessary. Key properties: it is constantly refined as the team learns; higher-priority items carry more detail so they are work-ready (lower items may be one-line placeholders); it includes not just feature work but support, maintenance, non-functional requirements, and research; and the Product Owner owns it and prioritizes it.

Sprint Backlog. The subset of product backlog items the team commits to for one sprint, selected during sprint planning: the sprint's to-do list. Entering the sprint backlog is a commitment; entering the product backlog is merely a possibility.

The Increment: Potentially Shippable Work. Each sprint aims to produce a potentially shippable product increment: work that is genuinely done (built, checked in, tested) whether or not the business chooses to ship it immediately. The mantra: outcome over output; quality of work over quantity of work.

Scrum is fierce about finishing. Work in progress is a form of waste: unfinished work delays the whole workflow and, worse, means you are not learning from completed, tested reality. Teams cultivate swarming (affectionately, dog piling): everyone piling onto the last 20 percent of an item to drag it over the finish line before starting something shiny and new. Half-baked cake feeds no one.

Two definitions bracket every work item's life:

• Definition of Ready: the standard checklist an item must satisfy before work starts: clear, estimated, acceptance criteria present. It exists to force the right conversations before anyone wastes a sprint on something unready or unneeded. (Notice: a BA's user stories and acceptance criteria from Module 4 are most of what "ready" means.)
• Definition of Done: the standard a work item must meet to be complete: built, tested, reviewed, deployed to the agreed environment. No private definitions; one shared standard.

The Ceremonies

Here is the write-once, reference-forever guide to Scrum's meetings. Salesforce's practice groups them into two families: planning meetings (aligning on what to build) and inspect-and-adapt meetings (improving the product and the process). None of them is a status meeting for its own sake; each is designed to produce action.

Lean Principles: The Cultural Layer

Alongside Scrum's mechanics, agile culture draws on Lean thinking. Salesforce adapted seven Lean values, and they are worth knowing because they explain why the mechanics work:

1. Respect People. People do not need to be told how to do their jobs. Managers act as servant leaders: they listen to their teams, hire good people, and let them work. Salesforce frames this with a concept that will be familiar here at home: its Ohana culture, drawn from the Hawaiian understanding that family, blood-related or adopted, are bound together and responsible for one another. Team success comes from mutual respect; individual heroics predict team failure.
2. Eliminate Waste. Only work on what adds customer value. Named wastes: multitasking, poorly run meetings, reactively assigned work, and unfinished work. The Definition of Ready exists precisely as a waste filter.
3. Deliver Fast. Short sprints mean constant learning about what works, and fast course correction.
4. Just-in-Time Decisions. Avoid heavy up-front design; delay crucial decisions to the last responsible moment, when you know the most. The team judges when that moment is.
5. Optimize the Whole. The system is more than the sum of its parts: no team succeeds in a vacuum. Think big, act small, fail fast, learn rapidly.
6. Create Knowledge. Amplify learning: document decisions, share discoveries, teach each other.
7. Build Quality In. Quality is not inspected in at the end; it is built in from the start (a theme Module 12 picks up as verification versus validation).

Kanban: The Other Workflow

Kanban (Japanese for "visible sign") is the second major agile workflow: less prescriptive than Scrum, easier to adopt, and favored by operations-flavored teams: support, infrastructure, production issues. Four key traits:

1. Visualize workflow. Every piece of work becomes a card on a board (physical or virtual), moving through columns that map the workflow stages. Everything visible, always.
2. Limit work in progress (WIP). Teams cap how many items may occupy each workflow stage at once. Hit the limit and the team swarms to unblock before pulling new work. Where Scrum limits work per sprint, Kanban limits work per stage: same anti-waste instinct, different mechanism. WIP limits are set experimentally: pick one, observe, adjust at the retrospective.
3. Incremental, evolutionary change. Kanban favors small continuous adjustments over big process shifts, and it embraces last-minute change: new urgent work slots into the board today, no waiting for the next sprint boundary.
4. Metrics built in. Cycle time: days to complete one item once work starts (optimize it to be small and predictable: the same cycle-time concept you measured against takt time in Module 5). Throughput: work completed per period. Together they make delivery predictable without sprint-sized batches.

Choosing: Scrum, Kanban, or Scrumban

At Salesforce, about 70 percent of teams use Scrum, 20 percent Kanban, and the rest a blend. Four questions decide:

• Is the team focused on predictability and productivity on large projects? Building a new website decomposes into plannable chunks with sprint-by-sprint review: Scrum. Responding to service outages cannot be planned two weeks ahead: Kanban.
• How far ahead can the team plan? Backlog full of plannable chunks: Scrum. Priorities changing constantly, difficulty committing to two weeks of scope, a quarter or more of work changing mid-sprint: that is interruption-driven work, and Kanban fits.
• Is new work truly an emergency? Before declaring work interruption-driven, test it: do the interruptions genuinely prevent finishing more valuable work first? Kanban does not help a team whose "emergencies" could actually wait for planning.
• How fast must new work be delivered? Same-day urgency favors Kanban's continuous flow.

Scrumban is the pragmatic hybrid: Kanban's flow and WIP limits, with Scrum's proven roles and meetings retained because they work. Many Salesforce managed-services and support teams (the kind you may join after go-live: see Module 14) run exactly this.

The RAID Log

One artifact appears on virtually every consulting project regardless of methodology, and the BA very often maintains it: the RAID log, tracking four things:

• R: Risks. Potential problems that could negatively affect the project. Identified proactively so they can be mitigated before they become larger issues: early identification prevents major problems down the line.
• A: Actions (and Assumptions). Action items that must be completed, each with a clear owner so there is no confusion about responsibility. Assumptions are things the team is trusting will go a certain way (a client's reaction, a data source's quality): written down so they can be tested rather than discovered.
• I: Issues. Unexpected problems that pop up during the project: risks that came true, and surprises nobody predicted. Proper issue tracking preserves how each was resolved, and when new issues recur, the log helps identify root causes (your 5 Whys from Module 5 apply directly).
• D: Decisions (and Dependencies). Decisions are the concrete choices made along the way, recorded so they stay made: nothing burns time like re-litigating a settled decision. Dependencies are tasks relying on the completion of other tasks: managed so the team stays aligned and sequenced (the critical-path thinking from Module 5).

Review the RAID log on a standing cadence: a stale RAID log is a decorative one.

Work-Tracking Tools: A Brief, Deliberate Note

Agile teams track epics, features, stories, tasks, issues, and bugs (the Module 4 hierarchy) in dedicated tools: Azure DevOps and Jira are the names you will hear most. These platforms provide backlogs and boards (Scrum and Kanban style), test-management features, history and audit trails, assignments and due dates, and reporting dashboards: one source of truth replacing scattered spreadsheets, documents, and email threads.

This course deliberately does not teach any specific tool's mechanics, because every firm configures and uses these tools in its own way, and tool skills are learned in days on the job. What transfers is everything else in this module: if you understand backlogs, stories, sprints, and ceremonies, any tracking tool is just the place those concepts live. The general flow you will recognize everywhere: requirements catalog built and signed off during discovery → loaded into the tool → groomed and estimated → planned into sprints → built and demoed → tested with bugs tracked → deployed. Expect a day-one orientation to any given firm's setup, and expect it to be enough.

The BA's Sprint, Ceremony by Ceremony

Pulling it together: here is what you concretely do in each ceremony on a typical Salesforce project.

• Backlog refinement: your home field. Bring stories drafted from discovery; sharpen acceptance criteria live; answer clarifying questions or take them back to stakeholders; split oversized stories; confirm items meet the Definition of Ready.
• Sprint planning: represent the business intent behind each story; answer "what does this mean?" so estimation is honest; help articulate the sprint goal in business language.
• Daily standup: report your own work (stories clarified, UAT prep, documentation); listen for blockers that are really requirements questions, and take them as actions; keep client answers flowing to the team.
• Sprint review/demo: frequently the narrator. Frame each demo item with the business problem it solves; capture stakeholder feedback verbatim; translate reactions into new or adjusted backlog items.
• Sprint retrospective: contribute honestly about process friction (late requirements? unclear stories? that is yours to own and improve); volunteer for improvement actions.
• Between ceremonies: maintain the RAID log with the PM, keep the RTM current (Module 4), prep test scenarios (Module 12), and keep stakeholders warm (Module 16).

A BA fluent in this rhythm is not "supporting" the agile team. They are load-bearing.