05 Quiz: Scrum Fundamentals
January 2026 (2670 Words, 15 Minutes)
New: Interactive Quiz Available!
Want to track your progress and get instant feedback? Try our new interactive version with progress tracking, immediate explanations, and score calculation.
Instructions
- This quiz tests your understanding of Scrum from Chapter 05 (Agile Development)
- Each question has 4 options with exactly one correct answer
- Focus on understanding the WHY behind Scrum, not just memorizing terms
- Sections: Roles, Board Analysis, V-Model vs Agile, Sprint Events
Section 1: Scrum Roles
Question 1: Product Owner Responsibility
A customer approaches the team during a sprint and says “I need this new feature added immediately!” Who should respond to this request?
A) The Scrum Master should add it to the sprint since they manage the team B) The Development Team should estimate it and add it if they have capacity C) The Product Owner should evaluate priority and decide if it’s worth interrupting the sprint D) The customer should wait until the retrospective to raise new features
Show Answer
Correct Answer: C
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).
Question 2: Scrum Master Role
The Development Team has been blocked for two days because they need access to a production server, but the IT department hasn’t responded to their request. Who should escalate this?
A) The Product Owner, since they represent business interests B) The Scrum Master, since removing impediments is their responsibility C) The most senior developer, since it’s a technical issue D) No one - the team should wait patiently and work on other tasks
Show Answer
Correct Answer: B
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.
Question 3: Technical Decisions
The team is debating whether to use React or Vue.js for the frontend. There are valid arguments for both. Who makes the final decision?
A) The Product Owner, since they decide what gets built B) The Scrum Master, since they facilitate team decisions C) The Development Team, since technical decisions are their domain D) The stakeholders, since they’ll use the final product
Show Answer
Correct Answer: C
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.
Question 4: Sprint Demo
At the Sprint Review, the team demonstrates a feature that works but doesn’t quite match what the stakeholders expected. Who has the authority to accept or reject this work?
A) The Scrum Master, since they ensure quality B) The Development Team, since they built it C) The Product Owner, since they represent stakeholder interests D) The stakeholders directly, since they’re the end users
Show Answer
Correct Answer: C
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.
Question 5: Task Assignment
During Sprint Planning, the Product Owner says “I want Developer A to work on the database task because they’re the expert.” Is this appropriate?
A) Yes, the PO should ensure the right people work on the right tasks B) No, the PO decides WHAT gets built, not WHO builds it or HOW C) Yes, but only if the Scrum Master approves the assignment D) No, only the Scrum Master can assign tasks to team members
Show Answer
Correct Answer: B
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.
Question 6: Scrum Master as Manager
A new Scrum Master starts tracking how many tasks each developer completes per day and uses this data in their performance reviews. What’s wrong with this approach?
A) Nothing - this is good data for continuous improvement B) The Scrum Master should not act as a manager or evaluate individual performance C) The data should include story points, not just task counts D) Performance reviews should only happen during retrospectives
Show Answer
Correct Answer: B
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.
Question 7: Role Overlap
In a small team of 4 people, can one person be both the Product Owner and a Developer?
A) Yes, this is common and perfectly acceptable in Scrum B) No, the PO must be a dedicated role separate from the team C) It’s possible but creates a conflict of interest between WHAT and HOW D) Only if the Scrum Master approves the dual role
Show Answer
Correct Answer: C
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.
Section 2: The Scrum Board
Question 8: Board State Analysis
You look at the team’s Scrum board and see: 0 items in “To Do”, 8 items in “In Progress”, 1 item in “Review”, 0 items in “Done”. The sprint is 50% complete. What does this indicate?
A) The team is working very efficiently on many things at once B) Too much Work in Progress (WIP) - the team is spreading themselves too thin C) The team needs more items in their sprint backlog D) This is a healthy board state showing good parallelization
Show Answer
Correct Answer: B
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.
Question 9: Stale Board
The Scrum board hasn’t changed in 3 days. The Daily Scrum discussions are brief with “still working on the same thing” from everyone. What’s likely happening?
A) The team is in a productive “flow state” and shouldn’t be interrupted B) There are hidden blockers that aren’t being surfaced or addressed C) The sprint was well-planned and everything is on track D) The team doesn’t need the board since they communicate well
Show Answer
Correct Answer: B
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.
Question 10: Board Ownership
During the sprint, the Product Owner sees that a high-priority item is still in “To Do” and moves it to “In Progress” themselves, assigning it to a specific developer. What’s wrong with this action?
A) The PO should have asked the Scrum Master first B) The PO violated role boundaries - the team owns the board and pulls their own work C) Nothing is wrong; the PO is ensuring priorities are respected D) The PO should have moved it to “In Review” instead
Show Answer
Correct Answer: B
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.
Question 11: Why Boards Matter
A team argues that they don’t need a physical or digital board because they have good communication and everyone knows what everyone else is working on. What’s the main risk of skipping the board?
A) They’ll fail their Scrum certification requirements B) They lose transparency - hidden assumptions about status lead to surprises C) The Scrum Master won’t have anything to do D) They’ll work slower without visual motivation
Show Answer
Correct Answer: B
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).
Section 3: V-Model vs. Agile
Question 12: Late Feedback Problem
In the V-Model, testing happens after development is complete. What is the primary problem this causes?
A) Testing takes too long because developers have moved on to other projects B) Defects found late cost 30-100x more to fix than defects found early C) Testers don’t understand the code as well as developers D) The test environment is difficult to set up
Show Answer
Correct Answer: B
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.
Question 13: Requirements Assumption
The V-Model assumes “we can know all requirements upfront.” Why is this assumption problematic?
A) Requirements documents take too long to write B) Stakeholders are not available for requirements gathering C) Users don’t know what they want until they see working software D) Requirements tools are too expensive for small teams
Show Answer
Correct Answer: C
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.
Question 14: Change Handling
A major requirement changes 6 months into a 12-month V-Model project. What typically happens?
A) The team easily accommodates the change since requirements are just documents B) Expensive rework: specifications, designs, and possibly code must all be updated C) The change is rejected because the project is too far along D) Only the test plans need to be updated
Show Answer
Correct Answer: B
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.
Question 15: When V-Model Works
Despite its limitations, the V-Model may still be appropriate in some contexts. Which scenario might justify using a V-Model approach?
A) A startup building a new mobile app with frequent pivots B) A medical device requiring FDA certification with mandatory documentation C) A web application with weekly releases D) An internal tool where requirements change monthly
Show Answer
Correct Answer: B
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.”
Section 4: Sprint Events
Question 16: Sprint Planning Output
What are the TWO key outputs of Sprint Planning?
A) Updated Product Backlog and team assignments B) Sprint Backlog and Sprint Goal C) Test plan and deployment schedule D) Technical design and time estimates
Show Answer
Correct Answer: B
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.
Question 17: Daily Scrum Purpose
What is the primary purpose of the Daily Scrum (standup)?
A) To report progress to the Scrum Master B) To synchronize the team and identify blockers for the next 24 hours C) To assign tasks for the day D) To update the burndown chart
Show Answer
Correct Answer: B
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.
Question 18: Sprint Review vs. Retrospective
What’s the key difference between Sprint Review and Sprint Retrospective?
A) Review is for developers; Retrospective includes stakeholders B) Review inspects the PRODUCT (what was built); Retrospective inspects the PROCESS (how we worked) C) Review happens weekly; Retrospective happens monthly D) Review is optional; Retrospective is mandatory
Show Answer
Correct Answer: B
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.
Question 19: Sprint Cancellation
Under what circumstances can a Sprint be cancelled before its end date?
A) Never - sprints are never extended or shortened B) When the Product Owner determines the Sprint Goal has become obsolete C) When the team realizes they can’t complete all committed work D) When a critical bug is found in production
Show Answer
Correct Answer: B
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.
Question 20: Retrospective Action Items
The team’s retrospective identifies that “code reviews take too long and block progress.” What should happen next?
A) The Scrum Master should mandate shorter review times B) The team should add a specific action item to improve this in the next sprint C) This should be escalated to management for a process change D) The team should skip code reviews to move faster
Show Answer
Correct Answer: B
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 (D) creates technical debt; escalating to management (C) removes team ownership. The SM doesn’t mandate solutions (A) - they facilitate the team finding their own.
Summary
Key Concepts Tested:
- Roles: PO decides WHAT, Team decides HOW, SM removes impediments
- Board: Transparency enables collaboration; watch for WIP overload
- V-Model vs. Agile: Late feedback is expensive; embrace change through short cycles
- Events: Each ceremony has a specific purpose; don’t skip them
Ready for more? Review the lecture slides and try the Sprint Game exercise!