05 Quiz: Scrum Fundamentals

The Product Owner owns the Product Backlog and is the single voice for prioritization. They decide WHAT gets built and in what order. If a new feature is truly urgent, the PO might negotiate with the team to swap it for existing sprint work, but this decision belongs to the PO - not the SM (who handles process) or the team (who decides HOW to build).

Removing impediments is a core Scrum Master responsibility. When the team is blocked by something outside their control (like IT access, bureaucracy, or organizational issues), the SM escalates and resolves it. The SM acts as a “servant-leader” who protects the team from distractions and removes obstacles so they can focus on delivery.

The Development Team decides HOW to build things. Technical choices like frameworks, architecture, and implementation details belong to the people doing the work. The PO decides WHAT to build (features, priorities), but not HOW. The SM facilitates but doesn’t make decisions for the team.

The Product Owner accepts or rejects completed work based on whether it meets the Definition of Done and acceptance criteria. While stakeholder feedback is valuable (and gathered at the Sprint Review), the PO is the single decision-maker to avoid conflicting instructions. If stakeholders disagree, they negotiate with the PO, not directly with the team.

In Scrum, work is PULLED by team members, not ASSIGNED by anyone. The Development Team self-organizes to decide who works on what. The PO’s role is to prioritize the backlog (WHAT), not manage the team (HOW/WHO). Even the Scrum Master doesn’t assign tasks - they remove impediments and coach the team on Scrum practices.

The Scrum Master is NOT a manager. Using task counts for performance reviews creates individual competition that hurts team collaboration. In Scrum, the team succeeds or fails together - there’s no “my tasks” vs “your tasks.” The SM facilitates the process and removes impediments; they don’t manage people or evaluate performance.

While small teams sometimes combine roles out of necessity, having one person be both PO and Developer creates tension. As PO, you might want feature X first; as Developer, you might prefer to work on feature Y because it’s more interesting technically. The separation exists to maintain objectivity in prioritization. If you must combine roles, be aware of this conflict.

Having 8 items in progress with none done at the midpoint is a classic “too much WIP” problem. When people work on too many things simultaneously, context-switching hurts productivity and nothing gets finished. A healthy pattern is: start fewer things, finish what you started, then pull more work. The board should flow left-to-right, not pile up in the middle.

A stale board usually indicates hidden problems. If nothing has moved in 3 days, tasks are either blocked (and no one is escalating), poorly defined (and people are spinning), or the team isn’t updating the board. The Daily Scrum should surface these issues - “I’ve been stuck on X because of Y” - so the SM can help resolve them.

The Development Team owns the Sprint Backlog and decides how to execute the work. The PO set priorities during Sprint Planning; during the sprint, they should not micromanage the board. If the PO is concerned about progress, they should raise it at the Daily Scrum or with the SM, not directly move cards or assign work.

The board is an “information radiator” - it makes work visible to everyone without needing to ask. Without it, you rely on everyone’s memory and assumptions, which drift over time. “I thought you were done with that!” and “I didn’t know you were blocked!” become common. The board enables transparency, one of Scrum’s three pillars (alongside Inspection and Adaptation).

Barry Boehm’s research showed that the cost to fix a defect increases exponentially as you move through development phases. A requirements error found during requirements costs 1x to fix; the same error found in production costs 30-100x more. The V-Model’s sequential phases mean problems aren’t discovered until late, when they’re most expensive.

This connects to Herbert Simon’s “bounded rationality” - humans can’t fully predict complex systems. Users often don’t know what they need until they interact with a working prototype. The classic example: “I said I wanted X, but now that I see it, I realize I actually need Y.” Agile embraces this by delivering working software early and iterating based on feedback.

In a sequential process, a requirements change cascades through all downstream artifacts. The specification must change, which invalidates the design, which requires code changes, which requires new tests. Each phase’s documentation must be reworked. Agile minimizes this by working in short cycles where “change” is just reprioritizing the backlog - not rewriting months of documentation.

Regulated industries (medical, aerospace, automotive safety) often require extensive documentation for certification. The V-Model’s explicit phase-to-test mapping provides the traceability auditors need. However, even these industries are adopting Agile practices within regulatory constraints - the US Army example shows that “regulated” doesn’t mean “must use waterfall.”

Sprint Planning produces: (1) The Sprint Backlog - the items selected from the Product Backlog plus a plan for delivering them, and (2) The Sprint Goal - a short statement of what the sprint aims to achieve. The Sprint Goal provides focus and flexibility: if specific items can’t be completed, the goal might still be achieved through alternative approaches.

The Daily Scrum is for the Development Team to synchronize with each other - not to report to anyone. The classic three questions (What did I do? What will I do? What’s blocking me?) help identify who needs help, what’s stuck, and how to coordinate. It’s not a status report meeting - it’s a planning meeting for the next 24 hours.

The Sprint Review examines the product - the team demos what was completed, stakeholders provide feedback, and the Product Backlog may be updated based on learning. The Sprint Retrospective examines the process - what worked well, what didn’t, and what to improve next sprint. Both are essential but have different focuses.

Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete (e.g., the company pivots, the market changes dramatically). Sprint cancellations are rare and disruptive. Note: incomplete work is NOT a reason to cancel - it simply returns to the backlog. The sprint still ends on time, and the team reflects on why work wasn’t completed.

Retrospectives should produce concrete, actionable improvements. “We’ll try pairing on reviews to make them faster” or “We’ll add a review SLA of 4 hours” are good action items. The team owns their process and experiments with changes. Skipping quality practices creates technical debt; escalating to management removes team ownership. The SM doesn’t mandate solutions - they facilitate the team finding their own.