Applying Agile 0x0001
Scrum notes reorganized around the official November 2020 revision of the Scrum Guide (Ken Schwaber, Jeff Sutherland). This corrects inaccurate statements mixed into the old notes—"iteration == Sprint," "shorten the Daily meeting according to the previous day's duration," and "the repetition of measure → modify is Scrum itself"—against the original guide.
Definition and theoretical foundations of Scrum
Scrum is "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." It matters that Scrum is a framework, not a methodology. The guide is intentionally purposefully incomplete: instead of detailed work instructions, it defines only the minimum rules governing relationships and interactions among people. The collective intelligence of the team using it fills in the technologies and techniques applied within it.
Scrum is founded on empiricism and lean thinking. Empiricism asserts that "knowledge comes from experience and making decisions based on what is observed." This corrects a common misunderstanding: Scrum is not "a general measurement practice that continuously measures arbitrary metrics." Empiricism is embodied in the following three pillars.
- Transparency: work and process must be visible both to those performing the work and to those receiving the result. Artifacts with low transparency lead to decisions that diminish value and increase risk.
- Inspection: artifacts and progress toward agreed goals are inspected frequently and diligently to detect undesirable variance early. Scrum's five events provide the cadence for this inspection.
- Adaptation: when a process moves beyond acceptable limits or its result becomes unacceptable, it is adjusted immediately. The guide explicitly states that "inspection without adaptation is considered pointless."
The phrase "measure → modify → measure → modify" is therefore only half right. Measurement (inspection) is a means; Scrum is the complete cycle of inspection on top of transparency and immediate adaptation based on the result. External measurement techniques such as statistical process control (SPC) are not elements prescribed by Scrum, but optional supporting techniques that may be used within the framework.
A Sprint is not synonymous with an arbitrary "iteration"
The old note's "iteration == Sprint" requires correction. An iteration is the general concept of repeating some work, while a Sprint is a specific event defined by Scrum together with rules. The guide places the following conditions on it.
- It has a fixed length of one month or less. A new Sprint starts immediately after the previous Sprint ends, and its length is not changed frequently, preserving consistency.
- It is the container for all other events. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and all the actual work happen inside the Sprint.
- During the Sprint, no changes are made that would endanger the Sprint Goal, and quality does not decrease, while the Product Backlog is refined as needed. Scope may be clarified and renegotiated with the Product Owner as more is learned.
- Every Sprint must create a usable Increment in a Done state. The guide says each Sprint may be considered "a short project."
- A Sprint is canceled only when the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.
A Sprint provides predictability not merely because "development was split into smaller pieces," but because a cadence for inspecting and adapting progress toward a goal is structurally guaranteed at least once a month. The guide warns that an excessively long Sprint can invalidate the Sprint Goal and increase complexity and risk.
The Scrum Team and accountabilities
The fundamental unit of Scrum is one Scrum Team, consisting of one Scrum Master, one Product Owner, and Developers. It is typically 10 or fewer people, with no subteams or hierarchies. The team is both cross-functional—possessing all the skills needed to create value each Sprint—and self-managing, internally deciding who does what, when, and how without outside interference. The guide uses the term "accountability," not "role."
- Product Owner: accountable for maximizing the value of the product resulting from the Scrum Team's work. The Product Owner develops and explicitly communicates the Product Goal; creates and clearly communicates Product Backlog items; orders them; and ensures that the backlog is transparent, visible, and understood. The Product Owner is one person, not a committee, and stakeholders can try to change the backlog only by convincing that person. Success requires the entire organization to respect the Product Owner's decisions.
- Developers: the people committed to creating every aspect of a usable Increment each Sprint. They create the Sprint Backlog, the plan for the Sprint; instill quality by adhering to a Definition of Done; adapt their plan each day toward the Sprint Goal; and hold one another accountable as professionals.
- Scrum Master: accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. As a true leader who serves the team, the Scrum Master coaches self-management and cross-functionality, causes the removal of impediments to progress, and ensures that all Scrum events take place within their timeboxes and are positive and productive.
Events and timeboxes
Each of Scrum's five events is a formal opportunity for inspection and adaptation. Together they create regularity and minimize the need for meetings not defined in Scrum.
| Event | Purpose | Timebox (for a one-month Sprint) |
|---|---|---|
| Sprint | Container for all events and work | Fixed length of one month or less |
| Sprint Planning | Initiate the Sprint by laying out the work to be performed | Up to 8 hours |
| Daily Scrum | Inspect progress toward the Sprint Goal and adapt the Sprint Backlog | 15 minutes |
| Sprint Review | Inspect the Sprint's outcome and determine future adaptations | Up to 4 hours |
| Sprint Retrospective | Plan ways to increase quality and effectiveness | Up to 3 hours |
For shorter Sprints, each event is usually shorter as well.
A second correction is necessary here. The Daily Scrum is fixed at 15 minutes. The guide contains no rule for dynamically changing the timebox based on the previous day's result, such as "yesterday took 10 minutes, so schedule 10 minutes today." To reduce complexity, it is held at the same time and place every working day of the Sprint and is an event for Developers (if the Product Owner or Scrum Master is actively working on Sprint Backlog items, they participate as Developers). Developers may choose any structure and technique, but the focus must be on progress toward the Sprint Goal and an actionable plan for the next working day. For reference, the well-known three-question format—"what I did yesterday / what I will do today / impediments"—was removed from the guide's main text in the 2017 revision.
Artifacts and commitments
Scrum artifacts represent work or value. Each artifact has one commitment that ensures transparency and focus.
- Product Backlog — commitment: Product Goal. The backlog is an emergent, ordered list of what is needed to improve the product and the single source of work undertaken by the team. The Product Goal describes a future state of the product and is the Scrum Team's long-term objective; the team does not move to another objective until the current one is achieved or abandoned. The rest of the backlog emerges to define the "what" that fulfills the Product Goal.
- Sprint Backlog — commitment: Sprint Goal. It consists of the Sprint Goal (why), the Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). The Sprint Goal is the single objective for the Sprint. It is created during Sprint Planning and must be finalized before Planning ends. It is the Developers' commitment, but it gives flexibility in the exact work needed to achieve it and creates coherence and focus so the team works together rather than on separate initiatives.
- Increment — commitment: Definition of Done. An Increment is a concrete stepping stone toward the Product Goal, a usable result thoroughly verified to work together with all previous Increments. The Definition of Done is a formal description of the state in which an Increment meets the product's quality measures. An item that does not meet the DoD can neither be released nor presented at the Sprint Review; it returns to the Product Backlog. When an organizational DoD standard exists, every team must follow it as a minimum.
Distinguishing a forecast from a commitment
This is the third correction. The set of items Developers select during Sprint Planning because they believe they can finish them in the Sprint is a forecast, not a commitment. The guide says, "The more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts." The commitment, by contrast, is to the Sprint Goal. When work reveals that reality differs from the expectation, Developers collaborate with the Product Owner to renegotiate the Sprint Backlog's scope without affecting the Sprint Goal.
Ignoring this distinction and operating as though the team "unconditionally promised to finish every selected item" creates a death march of overtime and lower quality. That is not Scrum, but fixed-scope management borrowing Scrum's name. The guide recognizes the usefulness of progress-forecasting practices such as burn-downs, burn-ups, and cumulative flows, but adds: "these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."
Risk and short feedback loops
Scrum's main mechanisms for reducing risk are timeboxes and the inspection-adaptation cadence. The guide says, "Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame." This means more frequent opportunities for inspection can reduce the time spent investing further in the wrong direction; it does not guarantee that every loss is limited to the cost of one Sprint.
A big-bang approach—integrating and verifying everything at the end—carries a high risk of discovering directional errors late. The Sprint approach offers an opportunity at the end of every Sprint to inspect a usable Increment with stakeholders, increasing the chance of earlier adaptation. However, latent defects and incorrect market assumptions do not reveal themselves automatically. Effectiveness depends on the Increment's transparency, stakeholder participation, and the quality of inspection. The terms "upside risk / downside risk" mentioned in the old note come from finance and general risk management, not the Scrum Guide.
Example: flow of a one-week Sprint
The following is an example that proportionally shortens the timeboxes for a one-month Sprint. The guide says only that events are usually shorter for shorter Sprints, so these durations are operating examples, not rules.
- Monday 10:00 — Sprint Planning (about 2 hours): The Product Owner presents the Sprint's value proposition, and the team finalizes the Sprint Goal (why). Developers select and forecast backlog items (what), then establish a work plan that satisfies the DoD (how).
- Every day 09:30 — Daily Scrum (15 minutes, same time and place): Inspect progress toward the Sprint Goal and adjust today's execution plan.
- Wednesday — Product Backlog refinement: Break down and add detail to candidate items for the next Sprint. Refinement is an ongoing activity, not a separate meeting.
- Friday 14:00 — Sprint Review (about 1 hour): Inspect the completed Increment with stakeholders, share environmental changes, and collaboratively determine what to do next. It is a working session, not a presentation.
- Friday 15:30 — Sprint Retrospective (about 45 minutes): Inspect the Sprint from the perspectives of individuals, interactions, processes, tools, and the DoD, then determine how to implement the highest-impact improvement as soon as possible. The team may add it to the next Sprint Backlog when appropriate. The Sprint ends, and the next Sprint starts immediately.
Measurement: useful metrics and a warning about gaming
Scrum does not prescribe particular metrics, but the following are often used as means of observation that support empiricism.
- Burn-up/burn-down charts and cumulative flow: visualize Sprint progress and bottlenecks. They are input to forecasts, not report cards.
- Throughput and cycle time: evidence for flow-based forecasting.
- Escaped defects: a quality signal for inspecting the effectiveness of the DoD.
- Sprint Goal success rate: a signal of whether the team works around goals rather than a list of tasks.
Always guard against Goodhart's law: "When a measure becomes a target, it ceases to be a good measure." Targeting velocity causes story-point inflation, and estimation units are relative values meaningful only within each team, making velocity comparisons between teams meaningless. Individual metrics such as points completed per person or lines of code destroy collaboration and self-management. Metrics align with empiricism only when used as evidence for inspection and adaptation, not as evaluation tools.
Common failure modes
- Zombie/mechanical Scrum: every event is held, but a lack of transparency, inspection, and adaptation means the outcome never changes.
- Daily Scrum as a status meeting: it degenerates into reporting status to a manager rather than Developers adjusting their plan.
- Powerless Product Owner: the person has no real authority, or a committee fills the accountability, so external pressure disrupts backlog ordering.
- Missing or negotiable DoD: compromising the DoD under deadline pressure accumulates technical debt in the Increment.
- Ignoring the Sprint Goal: assigning only tasks without a goal during Planning destroys focus and coherence.
- Skipping the Retrospective: adaptation stops, and the same problems recur every Sprint.
- Turning forecasts into commitments: forcing a forecast to become a scope commitment causes crunch and lower quality.
- Arbitrarily changing Sprint length: disrupting the cycle destroys the cadence of inspection and adaptation.
- Water-Scrum-fall: a crippled adoption that keeps requirements analysis and release as waterfall processes and runs Sprints only during development.
Adoption checklist
- Has everyone on the team read the original 13-page Scrum Guide at least once?
- Is there one Product Owner with real authority over backlog ordering and organizational respect for those decisions?
- Is the team 10 people or fewer, operating cross-functionally and through self-management without subteams?
- Is the Definition of Done documented and applied consistently to every backlog item?
- Is Sprint length fixed at one month or less, with all five events held within their timeboxes?
- Are the Product Backlog, Sprint Backlog, and Increment transparent to everyone?
- Does Sprint Planning always end with a finalized Sprint Goal?
- Do improvements selected in the Retrospective lead to concrete follow-up actions?
- Does every Sprint create a usable Increment, without using the Review as a release gate?
- Are metrics used only as evidence for inspection and adaptation, rather than performance evaluation?