Bachelors Program in Full Stack Development
Agile & Scrum Methodologies
•
Bachelor
Scrum Events and Iteration Execution
Introduction
Scrum is an empirical framework for developing, delivering, and sustaining complex products. Its effectiveness depends less on following meeting rituals than on using events to create transparency, inspect evidence, and adapt plans. A Sprint is a fixed-length period in which a Scrum Team creates a usable, valuable Increment. The events within it provide a recurring operating rhythm for product discovery, delivery, coordination, stakeholder learning, and improvement.
For a full-stack development team, Sprint execution may involve user-interface development, APIs, database changes, testing, security, deployment automation, documentation, and operational work. Scrum events help the team integrate these activities around a common Product Goal and a specific Sprint Goal. They also provide formal opportunities to reconsider scope without sacrificing quality or the team’s commitment.
This chapter explains how to plan and facilitate the four principal Scrum events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. It examines the relationship among the Product Backlog, Sprint Backlog, Sprint Goal, Increment, and Definition of Done; presents an applied case; and evaluates common failure modes, measurement practices, and contemporary considerations such as remote collaboration and AI-assisted development.
Learning Objectives
By the end of this chapter, you should be able to:
explain the purpose, participants, inputs, outputs, and facilitation practices of each Scrum event;
formulate a meaningful Sprint Goal and use it to guide scope decisions;
collaboratively select and decompose Product Backlog Items into a realistic Sprint Backlog;
distinguish the Daily Scrum from a status meeting;
conduct a Sprint Review as a working session for inspection and adaptation;
convert retrospective observations into specific, owned improvement actions;
assess flow, quality, and value without misusing metrics; and
identify ethical, technical, and organizational risks in Sprint execution.
Scrum’s Empirical Operating Model
Scrum is founded on empiricism: knowledge is based on observation and experience. Three pillars support empiricism:
Transparency means that important aspects of the process are visible and understood using a common standard. A Product Backlog, Sprint Goal, and Definition of Done must mean the same thing to the relevant participants.
Inspection means examining work and progress frequently enough to detect undesirable variance. Inspection should be useful, not disruptive or excessive.
Adaptation means changing the process or work when inspection reveals that current practices are ineffective. Adaptation is credible only when the team has authority and willingness to act.
The Scrum Team consists of a Product Owner, Scrum Master, and Developers. These are accountabilities rather than departmental job titles. The Product Owner maximizes product value and manages Product Backlog ordering. Developers create the Increment and are accountable for planning and delivering usable work. The Scrum Master helps establish Scrum, removes impediments, and coaches the organization and team.
A Sprint has a fixed duration of one month or less. It contains Sprint Planning, Daily Scrums, development work, a Sprint Review, and a Sprint Retrospective. The next Sprint begins immediately after the previous one. A Sprint should produce at least one usable Increment, and all work included in that Increment must meet the Definition of Done.
The central planning relationship
The Product Backlog is an ordered, evolving list of what may improve the product. During Sprint Planning, the team selects an achievable set of Product Backlog Items and develops a plan for delivering them. This selected work, the plan for delivering it, and the Sprint Goal form the Sprint Backlog.
The Sprint Goal is a single objective that gives the Sprint coherence while allowing reasonable flexibility in the exact work performed. It is not merely a list of tickets. For example, “complete tickets 41–47” is weak because it describes activity. “Enable new customers to securely reset a forgotten password without contacting support” expresses an outcome and supports decision-making.
Figure: Scrum events form a recurring cycle of planning, inspection, delivery, stakeholder learning, and improvement.
Sprint Planning
Sprint Planning initiates the Sprint. It is collaborative, and its maximum duration is eight hours for a one-month Sprint, proportionally less for shorter Sprints. The event addresses three questions: Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work be completed?
Establishing the Sprint Goal
The Product Owner proposes how the Sprint could increase product value. Developers and the Product Owner negotiate a goal based on product priorities, evidence, capacity, technical dependencies, and risk. The goal should be:
outcome-oriented rather than activity-oriented;
understandable to stakeholders;
sufficiently specific to guide trade-offs; and
achievable within the Sprint.
A useful test is whether the team can answer: “If unexpected work appears, how will this goal help us decide what to protect, defer, or remove?”
Selecting and decomposing work
Developers inspect the highest-value Product Backlog Items and assess whether they are sufficiently understood. Selection is not a command issued by the Product Owner; Developers make the forecast of what they can accomplish. Historical evidence may inform the forecast, but capacity, complexity, leave, incidents, and unfamiliar technology must also be considered.
Selected items are decomposed into tasks or other work units small enough to support daily coordination. Decomposition should expose design, implementation, integration, testing, security, accessibility, deployment, and documentation work. A task list is a planning aid, not a contract that prevents learning.
A Product Backlog Item should normally have a clear user or business purpose, acceptance conditions, dependencies identified where practical, and enough information for meaningful discussion. “Ready” checklists may help a team, but Scrum does not prescribe a formal Definition of Ready. Such checklists must not become a bureaucratic gate that delays valuable learning.
Scope management during Planning
Scope is negotiable; quality is not. If the team learns that selected work is larger than expected, the Product Owner and Developers may renegotiate which items support the Sprint Goal. They should not silently lower testing standards, security controls, accessibility, or the Definition of Done to make progress appear better.
A practical facilitation sequence is:
review the Product Goal and current product evidence;
propose a candidate Sprint Goal;
inspect the ordered Product Backlog and relevant technical information;
select a forecast of work;
identify dependencies, risks, and integration points;
decompose work and make the plan visible; and
confirm the goal, forecast, and quality standard.
The Scrum Master facilitates rather than dictates the plan. They help prevent premature solution debates, invite quieter participants, and ensure that disagreement is resolved through evidence and explicit assumptions.
The Daily Scrum
The Daily Scrum is a 15-minute event for Developers. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The familiar three questions—what did you do yesterday, what will you do today, and what impediments exist—are optional. A team may instead use a board walk, discuss the highest-risk work, or inspect progress against a Sprint Goal.
A useful Daily Scrum examines:
whether the Sprint Goal remains plausible;
which work is blocked or aging;
whether integration or quality risks are increasing;
whether Developers need to collaborate, swarm, or revise the plan; and
whether scope needs discussion with the Product Owner.
The event is not a reporting ceremony in which each person gives a manager a status statement. Detailed problem-solving should continue immediately afterward with only the relevant people. The Product Owner and Scrum Master may participate when useful, but the event remains Developers’ coordination forum.
Effective teams update the Sprint Backlog during or after the Daily Scrum. A board that shows work accurately is more valuable than a polished presentation. Remote teams need shared visual workspaces, explicit time-zone agreements, accessible communication, and an alternative for members who cannot attend synchronously.
Sprint Review
The Sprint Review occurs near the end of the Sprint and is a working session for inspecting the Increment and adapting the Product Backlog. It is not merely a demonstration or a formal acceptance ceremony. Participants may include the Scrum Team, customers, users, sponsors, operations staff, legal or security specialists, and other stakeholders relevant to the product.
A productive Review generally includes:
the Product Owner explains the Product Goal, current ordering, and value questions;
Developers describe what was completed and demonstrate the usable Increment;
participants inspect results, including evidence such as user feedback, performance data, defects, or operational observations;
stakeholders discuss changes in the market, technology, regulation, or user needs; and
the Product Backlog is adapted to reflect what has been learned.
Only work meeting the Definition of Done should be presented as part of the Increment. Incomplete work may be discussed transparently, but it is not counted as completed and does not create false confidence. A Review should focus on product outcomes rather than the number of tasks closed.
Feedback must be evaluated rather than accepted automatically. The Product Owner considers value, cost, risk, strategic alignment, and evidence when reordering the Product Backlog. Stakeholders provide insight but do not individually assign work to Developers or bypass the Product Owner.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect how the Sprint went with respect to people, interactions, process, tools, and the Definition of Done. It identifies the most helpful changes for improving quality and effectiveness. The team may address collaboration, estimation, technical practices, interruptions, inclusion, deployment, or organizational constraints.
Psychological safety is essential. A retrospective should examine systems and behaviors rather than seek scapegoats. A simple structure is:
establish a safe, focused purpose;
gather observations and data;
generate insights about causes and patterns;
decide which improvement matters most; and
define a small number of concrete actions.
An improvement action should have an owner, a completion condition, and a place in the next Sprint Backlog or team working agreement. “Communicate better” is vague. “For the next Sprint, the API developer and tester will pair on authentication changes before code review, measured by completion of the agreed test checklist” is more actionable. Improvement work is real work and must receive capacity.
Facilitation techniques include “start, stop, continue,” a timeline of events, five-whys analysis, and silent idea generation before group discussion. These techniques are aids, not substitutes for judgment. The facilitator should protect confidentiality while escalating systemic impediments when the team cannot resolve them alone.
Worked Application: The CampusConnect Password-Reset Sprint
The following is an illustrative case. CampusConnect is a university full-stack application used by students to register for activities. Support records show that password-reset requests are increasing, and students report delays during examination periods.
Background and problem. The Product Owner proposes a Sprint focused on reducing dependence on support staff while protecting account security. The team includes a Product Owner, Scrum Master, two frontend developers, two backend developers, a tester, and a platform engineer. The application uses a React interface, a REST API, and a relational database.
Planning. The proposed Sprint Goal is: “Enable verified users to securely reset forgotten passwords through a self-service flow.” Developers identify work involving the request screen, rate-limited reset tokens, email integration, password policy validation, audit logging, automated tests, accessibility, and deployment configuration. They discover that an existing email service has an undocumented quota. Rather than hide the risk, they include a technical investigation and agree with the Product Owner that a polished email template is less important than a secure, testable flow.
Execution. During the Daily Scrum, the team notices that frontend work is advancing while the token endpoint is blocked by a security review. Developers swarm around the endpoint, and the Product Owner helps clarify the user-facing error messages. Mid-Sprint, a request to add social-media login appears. The team records it in the Product Backlog rather than disrupting the Sprint Goal. A critical security vulnerability is treated differently: the Product Owner and Developers assess whether immediate action is required, and the Sprint plan is adapted transparently if so.
Review. The team demonstrates the complete flow in a staging environment. Stakeholders learn that some students cannot access their university email on mobile devices. The Product Backlog is reordered to investigate alternate verification support and clearer recovery guidance. The team also presents test evidence and explains that social-media login was not included.
Retrospective. The team identifies two causes of delay: security review began too late, and the shared test environment had unstable email delivery. They select two actions: involve the security specialist during refinement of authentication work, and create a deterministic email-testing service before the next security-related Sprint. Each action has an owner and a completion condition.
Outcome and learning. The Sprint produced a usable Increment and generated new product knowledge even though one proposed enhancement was deferred. Its success was not measured by the quantity of closed tickets. It was measured by alignment with the Sprint Goal, integrated quality, stakeholder learning, and improvement of the delivery system.
Scope, Quality, and Evidence
Scrum teams need evidence, but metrics can distort behavior. Useful evidence may include:
percentage of Sprint Goals achieved over time;
aging and blocked-time patterns for work items;
escaped defects and incident trends;
deployment frequency and recovery time;
usability or accessibility findings;
stakeholder and user feedback; and
improvement actions completed and their observed effects.
Velocity is the amount of work a team happened to complete in a previous period, often expressed in local estimation units. It is not a productivity measure, a universal benchmark, or a reliable comparison between teams. Forecasting based on historical throughput can be useful when item sizes and conditions are reasonably stable, but it remains uncertain. Teams should avoid turning velocity into a target because members may inflate estimates or select low-value work.
Quality is part of delivery, not a final inspection stage. The Definition of Done may include code review, automated tests, security scanning, accessibility checks, documentation, migration safety, observability, and deployment readiness. Its details depend on the product and organizational context, but lowering it to preserve a date creates hidden work and weakens transparency.
Challenges and Limitations
Several conditions commonly undermine iteration execution:
Overloaded Sprints: excessive work creates multitasking, unfinished items, and reduced quality. A smaller forecast is often more professional than an optimistic promise.
Unclear authority: if Developers cannot adapt their plan or the Product Owner cannot order the backlog, events become symbolic.
Component silos: separate frontend and backend queues delay integration. Cross-functional collaboration and vertical slices reduce this risk.
Stakeholder absence: a Review without relevant users or decision-makers reduces feedback quality.
Retrospective theatre: repeatedly recording the same problems without ownership indicates that the organization is not enabling adaptation.
Interruptions: support and operational work should be visible and capacity-aware. An explicit service policy may be needed rather than hidden interruption.
Distributed work: asynchronous updates, recorded demonstrations, and inclusive facilitation can supplement but not automatically replace valuable conversation.
Scrum is not a complete product-development method. It does not prescribe architecture, engineering practices, discovery methods, budgeting, or organizational design. Teams need complementary practices such as automated testing, continuous integration, threat modeling, user research, and release management.
Ethics, Governance, and AI-Assisted Development
Sprint decisions affect privacy, safety, accessibility, and fairness. Teams should consider whether a feature collects unnecessary personal data, creates discriminatory outcomes, excludes users with disabilities, or makes security assumptions that are not justified. Auditability and consent may be necessary in regulated contexts. A stakeholder’s urgency does not override legal or ethical duties.
AI coding assistants can help generate tests, explain code, or suggest refactoring, but they do not transfer accountability. Developers must review generated code for correctness, licensing constraints, insecure patterns, privacy leakage, biased assumptions, and maintainability. Sensitive source code or personal data should not be entered into tools without an approved governance basis. AI-generated output should meet the same Definition of Done as human-authored output, including testing and security review.
Best Practices for Facilitation
A Scrum Master and team can improve event quality by:
publishing a clear purpose and timebox for each event;
using visible evidence rather than opinion alone;
separating decision-making from exploratory discussion when necessary;
ensuring that the Sprint Goal remains visible;
inviting dissent and protecting less powerful participants;
recording decisions, assumptions, risks, and follow-up actions;
treating unfinished work transparently; and
reviewing whether each event produces its intended value.
The deepest principle is coherence: Planning establishes a valuable objective, Daily Scrums adapt the delivery plan, Reviews adapt the product direction, and Retrospectives adapt the way the team works. When these events are disconnected, Scrum becomes a schedule of meetings. When they reinforce one another, each Sprint becomes a controlled opportunity for learning and delivery.
Chapter Summary
Scrum events are mechanisms for empiricism, not ceremonial meetings. Sprint Planning creates a Sprint Goal, a forecast of work, and a delivery plan. The Daily Scrum enables Developers to inspect progress and adapt their plan. The Sprint Review connects the Increment to stakeholders, evidence, and Product Backlog adaptation. The Sprint Retrospective improves the team’s process, relationships, tools, and quality practices.
Scope may be renegotiated to protect the Sprint Goal, but the Definition of Done should not be weakened. Effective execution depends on transparency, collaborative authority, integrated quality, realistic forecasting, psychological safety, and visible improvement actions. Metrics should support learning rather than rank teams. Ethical, security, accessibility, privacy, and governance considerations belong inside the Sprint, not after it. In professional full-stack development, the value of Scrum lies in repeatedly converting plans and feedback into usable software and improved capability.
Key Terms
Empiricism: A way of working in which knowledge is built through observation, experience, and adaptation.
Sprint: A fixed-length period during which a usable Increment is created.
Sprint Goal: A single objective that gives a Sprint purpose and guides scope decisions.
Sprint Backlog: The Sprint Goal, selected Product Backlog Items, and the plan for delivering them.
Product Backlog: An ordered, evolving list of work that may improve the product.
Product Backlog Item: A unit of potential product work represented in the Product Backlog.
Increment: A usable, verified addition to the product.
Definition of Done: The shared formal description of the quality state required for work to count as complete.
Sprint Planning: The event that initiates a Sprint and establishes its goal and forecast.
Daily Scrum: A 15-minute Developers’ event for inspecting progress and adapting the plan.
Sprint Review: A stakeholder working session for inspecting the Increment and adapting the Product Backlog.
Sprint Retrospective: An event for improving the team’s process, interactions, tools, and quality.
Inspection: Examination of work and progress to identify undesirable variance.
Adaptation: Changing a plan, product direction, or process in response to inspection.
Impediment: An obstacle that limits progress toward the Sprint Goal.
Stakeholder: A person or group affected by, interested in, or able to influence the product.
Forecast: The Developers’ evidence-informed expectation of work that can be completed.
Vertical slice: A thin piece of functionality that crosses relevant layers and produces integrated value.
Psychological safety: A condition in which people can raise concerns, questions, and mistakes without fear of humiliation or retaliation.
Review Questions
Short Answer Questions
What are the three pillars of empiricism in Scrum?
Why is a Sprint Goal more useful than a list of completed tickets?
Who is primarily responsible for coordinating work during the Daily Scrum?
What is the main purpose of the Sprint Review?
Why should retrospective actions have owners and completion conditions?
Long Answer Questions
Explain how Sprint Planning connects the Product Goal, Sprint Goal, Product Backlog, and Sprint Backlog.
Compare the purposes and participants of the Daily Scrum, Sprint Review, and Sprint Retrospective.
Discuss how a team can manage changing scope while protecting quality and the Definition of Done.
Explain why velocity should not be used as a direct measure of developer productivity.
Evaluate the role of psychological safety in effective retrospective facilitation.
Analytical / Application Questions
A team has selected ten items, but a security review reveals that only six can safely be completed. Explain how the Product Owner, Developers, and Scrum Master should respond while preserving the Sprint Goal.
During a Review, users reject a feature that met all acceptance conditions. Analyze what this reveals about the difference between conformance and product value, and propose next steps.
A distributed full-stack team repeatedly carries work into the next Sprint because frontend and backend integration occurs at the end. Diagnose the likely planning and execution problems and design two measurable improvement actions.
Multiple Choice Questions with Answers
Question 1
Which statement best describes the purpose of the Sprint Goal?
A. It lists every task that each Developer must complete.
B. It provides a coherent objective that guides scope decisions during the Sprint.
C. It guarantees that all Product Backlog Items will be finished.
D. It replaces the Definition of Done.
Correct Answer: B. It provides a coherent objective that guides scope decisions during the Sprint.
Question 2
Who makes the forecast of what Developers can accomplish in a Sprint?
A. The Scrum Master alone
B. The Product Owner alone
C. The Developers
D. The stakeholders at the Sprint Review
Correct Answer: C. The Developers
Question 3
What is the primary purpose of the Daily Scrum?
A. To report individual performance to management
B. To approve the Product Backlog
C. To inspect progress toward the Sprint Goal and adapt the plan
D. To demonstrate the Increment to customers
Correct Answer: C. To inspect progress toward the Sprint Goal and adapt the plan
Question 4
Which work should be counted as part of the Increment?
A. Work that has passed the Definition of Done
B. Work that has been started by a Developer
C. Work listed in the Sprint Backlog regardless of status
D. Work verbally accepted by one stakeholder
Correct Answer: A. Work that has passed the Definition of Done
Question 5
What is a principal outcome of the Sprint Review?
A. A fixed commitment to repeat the same scope next Sprint
B. Adaptation of the Product Backlog based on inspection and feedback
C. Assignment of tasks by the Scrum Master
D. A private performance evaluation
Correct Answer: B. Adaptation of the Product Backlog based on inspection and feedback
Question 6
Which retrospective action is most specific and actionable?
A. Communicate better
B. Improve quality someday
C. Be more careful with testing
D. Pair on authentication changes and complete the agreed test checklist next Sprint
Correct Answer: D. Pair on authentication changes and complete the agreed test checklist next Sprint
Question 7
A team defers a lower-value item to protect a Sprint Goal. What Scrum principle does this illustrate?
A. Scope can be renegotiated while quality remains protected
B. The Definition of Done may be lowered to preserve scope
C. The Product Owner must assign all technical tasks
D. The Sprint must be cancelled whenever scope changes
Correct Answer: A. Scope can be renegotiated while quality remains protected
Question 8
Why is velocity a poor direct measure of productivity?
A. Velocity cannot be recorded numerically
B. Velocity is local, context-dependent, and can distort behavior when made a target
C. Velocity measures stakeholder satisfaction exactly
D. Velocity is defined by the Scrum Guide as revenue
Correct Answer: B. Velocity is local, context-dependent, and can distort behavior when made a target
Question 9
Which activity best reflects a Sprint Review?
A. Showing only screenshots of incomplete work
B. Inspecting a usable Increment with stakeholders and adapting the Product Backlog
C. Conducting individual salary discussions
D. Creating a private task list for the Scrum Master
Correct Answer: B. Inspecting a usable Increment with stakeholders and adapting the Product Backlog
Question 10
How should AI-generated code be treated in a Scrum team?
A. It is automatically complete because an AI produced it
B. It may bypass security and licensing review
C. It must meet the same quality, security, and Definition of Done standards as other code
D. It should be excluded from the Sprint Backlog
Correct Answer: C. It must meet the same quality, security, and Definition of Done standards as other code