Pass SMC Exam Guide

An Epic represents a high-level requirement that is generally too large or insufficiently detailed to be completed as a single User Story within one Sprint. As an Epic rises in priority and approaches implementation, it is progressively elaborated and decomposed into smaller User Stories.

SCRUMstudy explicitly states that some Epics/User Stories are initially too large to handle within one Sprint and are therefore broken into smaller User Stories when they move high enough in the Prioritized Product Backlog to be considered for upcoming Sprint work.

Smaller User Stories improve estimation, clarification, testability, and the team's ability to create potentially shippable increments within the Sprint time-box. They also enable the Product Owner to prioritize individual pieces of functionality according to value rather than treating a large requirement as one indivisible block.

Option A may be an indirect benefit but is not the fundamental reason. Team size does not determine whether an Epic must be decomposed, and review duration is not the defining criterion.

Therefore, the correct answer is that Epics are too large to be completed within a single Sprint.

Study Guide reference: Plan and Estimate - > Create User Stories - > Decomposition of Epics.

========

Velocity measures the amount of estimated work successfully completed by a Scrum Team during a Sprint. Where User Stories are estimated in story points, Sprint velocity is normally calculated by totaling the story-point values of the User Stories completed during that Sprint. SCRUMstudy explicitly describes velocity in these terms.

Velocity is particularly useful because historical values can support future Sprint planning and release forecasting. After several Sprints, a reasonably stable team can use its observed velocity to estimate how much work it is realistically capable of completing in a similar Sprint.

Business Value Delivered measures value rather than effort points. Number of Stories counts items without considering their relative size—a Sprint containing five small stories is not necessarily equivalent to one containing five large stories. A Sprint Burndown Chart shows remaining work over time during the Sprint rather than defining the quantity of story points successfully delivered.

Therefore, the metric that directly captures the number of completed story points per Sprint is Velocity.

Study Guide reference: Plan and Estimate - > Estimation; Implement - > Sprint Metrics; Velocity and Story Points.

========

SBOK emphasizes behavioral characteristics that enable a self-organizing and cross-functional team rather than requiring every individual to possess narrow specialist mastery or extensive Scrum theory. SCRUMstudy identifies desirable Scrum Team members as independent, self-motivated, customer-focused, responsible, and collaborative.

A Scrum Team member must be capable of working collectively toward shared Sprint objectives while taking personal ownership of assigned or selected work. “Independent” in this context does not mean isolated; it means being capable of taking responsibility without requiring command-and-control supervision. Collaboration remains essential because knowledge, work, risk, and accountability are shared across the team.

Options A, B, and C contain useful competencies, but they are not the defining combination sought by the question. A Scrum Team may contain generalist-specialists with differing domain and technical abilities, and not every member needs mastery of Scrum-specific tools or sophisticated negotiation capabilities.

The combination of collaborative, highly motivated, and independent most closely reflects the qualities needed for successful self-organization and collective ownership.

Study Guide reference: Organization - > Scrum Team - > Team Characteristics; Principles - > Self-organization and Collaboration.

========

Statement B is inaccurate because SBOK risk management operates across project, program, and portfolio levels. A risk may originate at the program or portfolio level yet affect one or more projects. In such circumstances, information about that risk must be communicated to the affected Product Owner and Scrum Team, while the risk can continue to be managed at the level where it originated. Serious portfolio/program risks can even cause a project team to reconsider or re-plan Sprint work.

Scrum's iterative structure also reduces exposure by creating short feedback cycles. Problems become visible sooner than in long sequential delivery models, allowing corrective action before excessive investment accumulates. Risk information can be communicated through artifacts such as Risk Burndown Charts.

Scrum's flexibility further assists risk management because approved changes can be incorporated into the Prioritized Product Backlog and prioritized for subsequent Sprints. This does not mean uncontrolled scope changes are introduced into an active Sprint; Sprint stability remains protected.

Therefore, the assertion that risks can only be managed at project level directly contradicts SBOK's treatment of program- and portfolio-level risk.

Study Guide reference: Risk - > Risks in Portfolios and Programs; Risk Identification, Assessment, Prioritization, and Communication.

========