Skip to main content
Engineering LibreTexts

4.2: SCRUM Guide

  • Page ID
    136323
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\dsum}{\displaystyle\sum\limits} \)

    \( \newcommand{\dint}{\displaystyle\int\limits} \)

    \( \newcommand{\dlim}{\displaystyle\lim\limits} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \(\newcommand{\longvect}{\overrightarrow}\)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    SCRUM Guide

    Scrum is one of the most widely used Agile frameworks because it gives teams a simple rhythm for handling complex work. It does not assume that every requirement, risk, dependency, and technical challenge can be fully predicted upfront. Instead, Scrum helps teams work in short cycles, inspect real progress, gather feedback, and adapt based on learning.

    For PMI-ACP, Scrum should not be understood as a set of ceremonies to memorize. It should be understood as a practical framework for empirical work. The exam often tests whether you know the purpose behind Scrum roles, events, artifacts, planning practices, and team behaviors. A team may have Sprints, Daily Scrums, Sprint Reviews, and Retrospectives and still not be truly Agile if those practices do not create transparency, inspection, adaptation, customer feedback, and team ownership.

    A simple way to remember Scrum is this:

    Scrum is not a meeting framework. Scrum is a timeboxed learning system.


    Scrum as a Timeboxed Empirical Framework

    Scrum is based on empirical process control. This means Scrum is designed for work where the team cannot know everything at the beginning. Instead of relying on a perfect upfront plan, the team learns through experience. It builds something usable, inspects the result, receives feedback, and adapts.

    The Sprint is the main container for Scrum work. A Sprint is a fixed-length timebox, commonly one to four weeks, during which the Scrum Team works toward a Sprint Goal and creates a usable product increment. The Sprint creates focus. It limits how long the team can go without inspecting real progress. It gives the team a regular rhythm for planning, building, reviewing, reflecting, and improving.

    Scrum works because it creates frequent learning moments. In a traditional approach, a team may spend months building before customers or stakeholders see anything real. In Scrum, the team creates regular opportunities to ask important questions: Is this still valuable? Are we solving the right problem? What did we learn? What should we change next?

    Scrum is built on three pillars: transparency, inspection, and adaptation.

    Transparency means the real state of the work is visible. The Product Backlog should show what matters most. The Sprint Backlog should show the team’s current plan. The Increment should show real product progress. The Definition of Done should show what quality means.

    Inspection means the team frequently examines the product, progress, and process. Scrum events create regular inspection points. The team inspects the plan during Sprint Planning, progress during the Daily Scrum, the product during the Sprint Review, and the process during the Sprint Retrospective.

    Adaptation means the team changes based on what it learns. The team may adjust the Product Backlog, improve its process, remove impediments, change technical practices, clarify acceptance criteria, or revise future plans.

    Scrum creates a simple learning rhythm:

    Plan. Build. Inspect. Adapt. Improve.

    This rhythm matters because complex work cannot be managed only through prediction. Product development, technology work, customer-facing solutions, and organizational change often involve uncertainty. Scrum does not eliminate uncertainty. It helps the team expose it earlier and respond to it more intelligently.

    Productivity May Drop Before It Improves

    When a team first adopts Scrum, productivity may appear to go down before it improves. This can surprise leaders who expected Agile to create immediate speed. In reality, the team is learning new roles, new events, new artifacts, and new behaviors. That learning takes time.

    Scrum also exposes problems that may have been hidden. Poor backlog quality becomes visible. Unclear priorities become visible. Technical debt becomes visible. Dependencies become visible. Delayed testing becomes visible. Blocked work becomes visible. This may make the team look slower at first, but the team may simply be seeing reality more clearly.

    A useful analogy is cleaning a messy garage. At first, things look worse because everything has been pulled out into the open. But that visibility is what makes real cleanup possible. In the same way, Scrum may initially expose confusion, overload, weak ownership, poor quality, and unclear priorities. Once the team can see these problems, it can improve them.

    Over time, productivity improves as the team builds rhythm, trust, shared understanding, better backlog quality, stronger technical practices, and better stakeholder feedback loops.

    PMI-ACP Connection

    In PMI-ACP questions, Scrum usually appears as a way to support learning and adaptation. Strong answers usually support transparency, inspection, adaptation, servant leadership, team ownership, and stakeholder feedback.

    Be careful with answers that treat Scrum as a ceremony checklist. The exam often rejects answers where Scrum is used as a command-and-control mechanism. For example, the Scrum Master should not assign tasks. The Daily Scrum should not become a manager status meeting. The Sprint Review should not be skipped because the work is imperfect. The Retrospective should not be ignored because the team is busy.

    For the exam, remember:

    Scrum is not about performing ceremonies. Scrum is about creating transparency, inspecting reality, and adapting based on learning.

    Empirical Scrum

    Empirical Scrum means the team learns by doing, inspecting, and adapting. The team does not depend on a perfect upfront plan. It depends on visible work, frequent feedback, and responsible adjustment.

    This is why Scrum is useful for complex work. When the solution is uncertain, the team needs a framework that helps it learn quickly.

    Myth: Scrum is just a set of meetings.
    The meetings only matter if they create transparency, inspection, and adaptation.

    Scrum Learning Loop

    Use this simple loop to remember how Scrum works:

    Plan
    The team selects valuable work and creates focus.

    Build
    The team creates a usable increment.

    Review
    The team inspects the product with stakeholders.

    Reflect
    The team inspects how it worked.

    Adapt
    The team updates the backlog, process, or plan based on learning.


    4.2: SCRUM Guide is shared under a not declared license and was authored, remixed, and/or curated by LibreTexts.

    • Was this article helpful?