Explanation:

A Sprint Review is the Scrum ceremony designed specifically to:
- Showcase the current build or increment
- Gather feedback from stakeholders
- Discuss what was completed versus what was planned
- Collaboratively decide what to do next

Since the business analyst is facilitating a meeting to review the build and collect stakeholder feedback, the Sprint Review is the most appropriate format. It ensures transparency, alignment, and continuous improvement.

🔍 Why not the others?

❌ A. Retrospective
A Sprint Retrospective is a meeting held after the sprint ends, focused entirely on the team’s internal processes and collaboration. It’s designed to reflect on what went well, what didn’t, and how the team can improve in future sprints. This meeting is not intended for stakeholders and does not involve reviewing the product or gathering feedback on the build. While valuable for continuous improvement, it doesn’t serve the purpose of showcasing deliverables or validating functionality with external participants.

❌ B. Daily Stand-up
The Daily Stand-up (or Daily Scrum) is a brief, time-boxed meeting (usually 15 minutes) held every day during the sprint. It’s meant for the development team only, where each member shares:
- What they did yesterday
- What they plan to do today
- Any blockers they’re facing

This meeting is not suitable for stakeholders, and it doesn’t include product demonstrations or feedback sessions. It’s purely tactical and focused on team progress, not on reviewing the build or engaging with business users.

📘 Reference:
Trailhead: Agile Basics
Scrum Guide: Sprint Review Ceremony

Question Recap

A BA needs to:

Explain a sales process improvement idea
Collaborate on a plan for implementation
Involve several sales users in different locations
Goal: Optimize effectiveness & build shared understanding

Answer Choices Analysis

A. Demo prototype

Useful when there’s already a working concept or system mockup.
Helps users visualize functionality, but in this scenario, the BA is still at the idea-sharing and collaboration stage, not prototyping yet.
So, while powerful later, it’s premature here.

B. Virtual whiteboard ✅ Correct Answer

Ideal for remote collaboration across different locations.
Allows brainstorming, mapping workflows, capturing input visually and collectively.
Optimizes effectiveness by engaging all participants simultaneously.
Builds a shared understanding since everyone contributes in real time and sees the same picture.
Salesforce BAs are encouraged to use collaboration tools (Miro, MURAL, LucidSpark, etc.) in multi-location sessions for process discussions.

C. One-on-one meetings

Effective for deep dives with individuals, but inefficient when the goal is shared understanding across multiple stakeholders.
Risks misalignment since different participants may walk away with different views.
Not optimal for group collaboration.

✅ Correct Answer: B. Virtual whiteboard

Explanation

A virtual whiteboard enables the BA to:

1. Bring together stakeholders from various locations.
2. Visually map out the current and future sales process.
3. Facilitate collaboration, brainstorming, and consensus-building.
4. Ensure alignment on the improvement idea and next steps.

This technique balances efficiency with inclusiveness, making it the best choice for this scenario.

Reference:

Salesforce Business Analyst Certification Guide emphasizes the BA’s role in facilitating workshops and using collaboration tools to build shared understanding of processes and solutions (Trailhead: Collaborate with Stakeholders as a BA).

Agile and Salesforce BA practices recommend visual, collaborative tools to align distributed teams.

Explanation:

Let’s line this up with the user story:
As a sales team manager, I want the ability to access reports on Sales Cloud to evaluate if the team's daily activities are meeting the set goals.

Good acceptance criteria should be:
Specific
Testable
Clearly tied to the user story’s goal

Why C is best
C. Able to view the sales team's reports

This is:
Directly related to the story’s need to access reports
Testable: during UAT you can literally confirm “Can the sales manager see the team’s reports in Sales Cloud?”

While it could be even more detailed in real life (e.g., “Able to view reports filtered to my team’s activities vs daily goals”), from the given options, C is the most appropriate and closest to proper acceptance criteria.

Why not A or B?

A. Able to monitor the sales team's performance

Too vague and high-level.
“Monitor performance” doesn’t specify how or where and isn’t clearly testable without further detail.

B. Able to click the Run button on sales reports

Overly technical and low-level.
Clicking “Run” is just a UI action; it doesn’t confirm that the manager can actually access the right reports and use them to evaluate daily activities vs goals.

Reference:
Salesforce and agile best practices emphasize that acceptance criteria should be clear, testable conditions that confirm when a user story is done—for example, a manager being able to access and view the necessary reports that support their business decision-making, rather than vague outcomes or purely technical UI actions.

Question Recap

Project just starting in Agile.
Product Owner wants BA to clearly define intended results of the work.
Results should be based on stakeholder needs, not assumptions.
The dev/implementation teams will use this definition to plan product decisions.
Focus is on stakeholder value.

Answer Choices Analysis

A. Requirements

Requirements are often detailed specifications (functional/non-functional).
In Agile, we avoid starting with heavy documentation and assumptions.
Also, “requirements” is more of a traditional waterfall term; Agile shifts toward value-driven artifacts.
Not the best choice here.

B. User Stories ✅ Correct Answer

User stories are the primary Agile tool to capture stakeholder needs.
Defined in the format: As a [role], I want [feature], so that [value].
This ensures focus on value and outcomes, not assumptions or technical detail.
They help dev teams make product decisions aligned with business value.
Perfect match to “clearly define intended results based on stakeholder needs.”

C. Epics

Epics are large bodies of work (containers for multiple user stories).
Useful for grouping high-level functionality, but too broad to directly guide product decisions at this stage.
Epics usually get broken down into user stories later.

✅ Correct Answer: B. User stories

Explanation

In Agile, user stories are the clearest way to define intended results:

They center on the stakeholder’s perspective and value.
They avoid assumptions by expressing needs in natural language.
They guide development teams to make informed product and design decisions.
They’re small enough to be actionable but still tied to business outcomes.

Epics can serve as placeholders at a very high level, but since the question stresses clear definition of intended results and focus on stakeholder value, user stories are the most precise and effective tool.

Reference

Agile Extension to the BABOK Guide – emphasizes user stories as the cornerstone of Agile requirement elicitation.

Salesforce Trailhead (Agile Basics for Admins and BAs) – stresses user stories as a way to capture stakeholder needs and value.

Explanation:

The goal is to launch a Minimum Viable Product (MVP) as soon as possible with only 16 hours of remaining capacity. To prioritize effectively, the BA must consider both the Priority and the Effort of each work item to maximize value within the constraint.

Let's analyze the options:

US-4007: Case Closure Action - Priority: High - Effort: 12 hours
US-4009: Case Age Reports - Priority: Medium - Effort: 4 hours

Total Effort for Option B: 12 hours + 4 hours = 16 hours

Why B is Correct:
Focus on High Priority First: US-4007 is the only "High" priority item. An MVP must include the most critical functionality, and a "Case Closure Action" is a fundamental part of a core service process (resolving customer issues).

Maximizing Value within Constraint: By selecting the high-priority item (12 hours) and pairing it with the lowest-effort item (4 hours), the team delivers the most critical feature plus an additional reporting feature, fully utilizing the 16-hour capacity. This delivers more value than any other combination that fits within the timebox.

Why A is Incorrect:
A. US-4008 and US-4009: This combination has a total effort of 16 hours (12 + 4), but it excludes the High priority item (US-4007) in favor of two Medium priority items. An MVP that lacks its highest-priority feature would not be viable.

Why C is Incorrect:
C. US-4009 and US-4010: This combination has a total effort of 16 hours (4 + 12), but it consists of one Medium and one Low priority item. This completely ignores the most critical work and would not result in a viable product.

Reference:
This scenario tests the Requirements Management and Project Governance competencies, specifically the ability to prioritize a backlog under constraints. The Salesforce Business Analyst exam guide expects BAs to be able to "Manage and prioritize requirements" and "Facilitate stakeholder communication and consensus," especially when scope and resources change. The decision correctly applies the MoSCoW method (Must-have, Should-have, Could-have) for prioritization, where the "High" priority item is the "Must-have" for the MVP, and the "Medium" item is a "Should-have" that can be included if capacity allows.