Applied Scrum Product Project

Introduction and Context

Scrum is learned most effectively by applying it to a real product problem. In a full-stack development project, students must integrate product discovery, backlog management, user-interface design, client-side programming, server-side development, data persistence, testing, deployment, teamwork, and professional communication. Scrum provides a framework for organising this work under uncertainty, but it does not replace technical competence or sound judgement.

This chapter presents a complete applied project model. The project is not merely an exercise in producing software. It is an opportunity to create a usable increment, make evidence-based decisions, maintain transparent artifacts, inspect progress, adapt plans, and critically evaluate both the product and the process.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Form and operate an effective Scrum team for a full-stack product.
2. Discover user needs and convert them into a coherent Product Goal and Product Backlog.
3. Plan, build, review, and retrospectively improve product increments.
4. Apply a technically meaningful Definition of Done without confusing it with Product Owner acceptance.
5. Maintain Scrum artifacts, team records, quality evidence, and delivery metrics.
6. Interpret empirical evidence and distinguish useful metrics from misleading measurements.
7. Collaborate professionally through inclusive communication, conflict management, and transparent decision-making.
8. Produce a structured critical evaluation of product outcomes and Scrum practice.

1. The Applied Scrum Project as an Empirical System

Scrum relies on empiricism: decisions are based on observation and experience rather than on unsupported prediction. Three empirical pillars are especially important:

• Transparency: the state of work, quality, risks, and decisions is visible.
• Inspection: people examine artifacts and progress frequently enough to detect undesirable variation.
• Adaptation: plans, practices, or the product are changed when inspection reveals a need.

A Scrum project has an account­able Product Owner, a Scrum Master, and Developers. These are accountabilities rather than compulsory job titles. The Product Owner maximises product value and manages the Product Backlog. The Scrum Master helps establish Scrum and removes impediments. Developers create a usable increment and are accountable for the technical work and quality.

The Product Owner may decide whether a feature is acceptable against stakeholder expectations, but acceptance is not a formal gate in the Definition of Done. The Definition of Done (DoD) is a shared quality standard indicating that an increment meets the team’s conditions for being considered complete and usable. A Product Owner can choose not to release, reorder the backlog, request clarification, or reject a backlog item because it does not satisfy its acceptance criteria; these actions do not turn Product Owner approval into a DoD criterion.

2. Selecting and Discovering a Product

A suitable student project has a real or realistic user group, a meaningful problem, and manageable technical boundaries. Examples include a community event platform, a campus equipment-booking system, or a small-business inventory application.

Discovery should begin with evidence rather than an assumed solution. The team can use interviews, observation, document analysis, surveys, and competitor review. Ethical discovery requires informed consent where appropriate, data minimisation, secure storage, and avoidance of deceptive claims.

A useful product framing statement contains:

• target users;
• problem or unmet need;
• context of use;
• expected value;
• constraints and risks;
• indicators that would suggest improvement.

The Product Goal describes a future state that gives the team a shared purpose. It should be concrete enough to guide backlog decisions but not so detailed that it becomes a technical specification.

Example Product Goal

“Enable campus societies to publish events and allow authenticated students to discover and register for them through a responsive web application.”

The goal does not prescribe a particular framework or database. Those are implementation decisions made in response to product and technical needs.

3. From Product Goal to Product Backlog

The Product Backlog is an ordered, evolving list of what is needed to improve the product. It may contain user-facing features, technical work, defects, research tasks, security improvements, and compliance work.

A useful backlog item expresses value and testable behaviour. A common format is:

As a [user], I want [capability], so that [benefit].

The format is a communication aid, not a substitute for analysis. Each item should be supported by notes on:

• user value;
• acceptance criteria;
• dependencies;
• risks and assumptions;
• design or data implications;
• approximate size or complexity.

Acceptance criteria describe conditions that help the Product Owner and team determine whether the intended behaviour has been delivered. They are not the same as the DoD. For example, acceptance criteria for event registration may require that an authenticated student can register once and receives a confirmation message. The DoD may require that the implemented feature is code-reviewed, tested, accessible, documented, integrated, and deployable.

Backlog refinement

Refinement is ongoing work in which the team clarifies, splits, estimates, and reorders items. An item is sufficiently prepared for Sprint Planning when its purpose is understood, its acceptance criteria are testable, major dependencies are visible, and the team can make a credible forecast. This is not a rigid “ready” gate mandated by Scrum; it is a useful team practice.

4. Planning the Product and Sprints

A project roadmap provides a tentative sequence of outcomes, not a guarantee of scope. A release forecast should identify assumptions and confidence levels. The team should avoid presenting velocity as a contractual production rate.

During Sprint Planning, the team establishes:

1. a Sprint Goal, explaining why the Sprint is valuable;
2. selected Product Backlog items that support the goal;
3. an actionable plan for producing a Done increment.

Developers make the forecast, taking account of capacity, complexity, dependencies, technical uncertainty, and the DoD. The Product Owner helps explain value and trade-offs, while the Scrum Master supports effective planning.

Capacity and forecast example

Suppose a five-person team has a ten-working-day Sprint. Each member has 7.5 productive hours per day, but planned leave, meetings, and support work reduce available development time. If the team estimates 250 total person-hours before adjustments and identifies 20% unavoidable non-project work, effective capacity is:

The unit is person-hours. This is a planning input, not a promise. If selected work is estimated at 190 person-hours, the forecast may be plausible, but uncertainty remains. Estimates are not measurements of value and should not be used to compare individuals.

5. Engineering the Full-Stack Increment

A full-stack increment should cross the relevant architecture rather than producing disconnected layers. A typical slice may include:

1. a responsive interface;
2. client-side validation and interaction;
3. an API endpoint;
4. server-side business rules;
5. database persistence;
6. authentication and authorisation where required;
7. automated tests;
8. deployment and operational documentation.

Vertical slicing allows the team to obtain feedback on a thin but usable capability. For example, “event registration” may initially support one registration path with a simple confirmation, rather than building an entire event-management architecture before any user-visible value exists.

Technical quality must include security and privacy. Teams should validate inputs on the server, protect credentials, apply least privilege, avoid storing unnecessary personal data, handle errors without exposing secrets, and consider accessibility. A prototype may use synthetic data, but it should not normalise unsafe practices that would be unacceptable in production.

6. A Defensible Definition of Done

The DoD should be agreed by the Scrum Team before or during early delivery and should become more demanding as capability matures. A sample DoD for a student full-stack product is:

• code is committed to the shared repository;
• peer review has been completed;
• automated unit or component tests relevant to the change pass;
• integration or API tests are run where applicable;
• acceptance criteria are demonstrably satisfied, with evidence recorded;
• accessibility and responsive behaviour have been checked for relevant interfaces;
• security checks appropriate to the feature have been completed;
• database migrations and configuration changes are documented;
• the increment is integrated with the main branch and can be deployed;
• user-facing and technical documentation is updated;
• no known critical defect prevents intended use.

This DoD is a quality agreement of the Scrum Team. It does not include “Product Owner acceptance” as a condition. Product Owner feedback and acceptance decisions remain important for product direction, but they are distinct from the team’s shared technical and quality standard.

A backlog item can satisfy its acceptance criteria and still fail the DoD, for example if it has not been tested or integrated. Conversely, a technically Done item may not be selected for release if the Product Owner determines that the product strategy, timing, or stakeholder needs have changed.

7. Events and Professional Collaboration

Daily Scrum

Developers inspect progress toward the Sprint Goal and adapt the plan for the next day. It is not a status report to a manager. Useful discussion focuses on progress, obstacles, dependencies, and coordination.

Sprint Review

The team must participate explicitly in the Sprint Review. The Scrum Team presents the results to relevant stakeholders, demonstrates the usable increment, discusses what changed in the environment, and collaborates on what to do next. Stakeholders provide feedback; the Product Backlog may be adjusted. A slide presentation without inspection of the product is weak evidence of a Sprint Review.

Sprint Retrospective

The team must also participate explicitly in the Sprint Retrospective. The participants inspect how the Sprint went with respect to people, interactions, practices, tools, and the DoD. They identify the most important improvement and agree on actionable changes. At least one improvement should be added to the next Sprint Backlog or otherwise made visible. A retrospective is not a blame session and should use evidence where possible.

Collaboration practices

Professional teamwork includes clear written decisions, respectful disagreement, timely escalation of impediments, inclusive turn-taking, and explicit ownership of follow-up actions. Psychological safety matters because defects and risks must be reported early. Conflict should be analysed as a difference in evidence, goals, constraints, or values rather than as a personal failure.

8. Project Evidence and Record Keeping

Assessment should evaluate observable evidence rather than claims that Scrum ceremonies occurred. A project evidence portfolio should contain:

Templates should be version-controlled or stored in a shared workspace with dates and authors. Records must not be fabricated retrospectively. If an event was missed, the team should record that fact and explain the consequence.

9. Metrics and Interpretation

Metrics support inspection; they do not define success by themselves. Useful measures include:

• Sprint Goal outcome: achieved, partially achieved, or not achieved, with explanation.
• Throughput: number of completed backlog items in a stated period. Items must have comparable scope for meaningful comparison.
• Cycle time: elapsed time from work beginning to completion for a defined work item.
• Defect trend: number and severity of defects discovered over time.
• Escaped defects: defects found after the team considered the item complete or after deployment.
• Deployment frequency: number of production deployments in a stated period.
• Stakeholder or user evidence: usability observations, task success, feedback, or adoption indicators.

For a set of n completed items with cycle times t₁, t₂, …, tₙ, the arithmetic mean cycle time is:

This measure is meaningful only when the start and end definitions are consistent. If three items take 2, 4, and 6 working days, the mean is:

The mean does not show variation. A median, range, or percentile may be more informative when a few items take much longer than others.

A simple completion ratio for a Sprint can be calculated as:

If 6 of 8 planned items meet the team’s completion definition, the ratio is 0.75, or 75%. This does not prove that the Sprint was successful: the team may have achieved an important Sprint Goal with fewer items, or completed low-value items while missing the goal.

Velocity, when used, should be treated as a local forecasting observation based on comparable completed work. It is not a productivity score, an individual performance measure, or a valid basis for cross-team ranking.

10. Illustrative Case: Campus Events Platform

Background

The fictional CampusConnect team consists of four student Developers, one student acting as Product Owner, and a Scrum Master. Their users are campus societies and students. Initial interviews reveal that event information is scattered across social media and email, while organisers have difficulty estimating attendance.

Problem

The team initially proposes a large platform with messaging, payments, recommendations, moderation, and analytics. Discovery shows that the most urgent problem is finding events and registering interest. The original proposal is therefore too broad for the available time.

Analysis

The team creates the Product Goal stated earlier and orders a thin first release around:

1. browsing published events;
2. viewing event details;
3. registering an authenticated student once;
4. allowing an organiser to view registration counts.

Risks include duplicate registration, unauthorised access to organiser data, and handling personal information. The team decides to use synthetic accounts during development and to store only necessary registration data.

Approach and solution

In Sprint 1, the team builds event listing and detail views backed by an API and seed database. The DoD requires automated API tests, peer review, responsive layout checks, and deployment to a test environment. During the Sprint Review, stakeholders report that filtering by date is more valuable than a decorative landing page. The Product Backlog is reordered accordingly.

In the Retrospective, the team observes that work was started in parallel across front end and back end without an agreed API contract. The improvement action is to write and review endpoint contracts before implementation. In Sprint 2, the team adds registration, server-side duplicate prevention, authentication checks, and confirmation feedback. Test evidence includes a successful registration, a rejected duplicate attempt, and an unauthorised access attempt.

Outcome

The team delivers a small but usable increment rather than an incomplete platform. The final report shows which Product Goal evidence was obtained, which assumptions remain uncertain, and which features were deliberately excluded. Stakeholders value the event search and registration flow, but accessibility testing identifies insufficient colour contrast in one component. The issue is documented as unfinished work rather than hidden by a favourable demonstration.

Learning points

The case demonstrates that value comes from solving a validated problem, not from maximising feature count. Review feedback can change backlog ordering. A technically sound DoD protects quality, while Product Owner and stakeholder feedback shape product decisions. Retrospective actions must be specific enough to observe in later work.

11. Critical Evaluation of Product and Process

The final evaluation should be structured rather than a narrative of activities. A strong report can use the following headings:

1. Product outcome: What user problem was addressed? What evidence supports the claim?
2. Scope and trade-offs: What was included, excluded, or deferred, and why?
3. Quality: How did the DoD, testing, security, accessibility, and deployment evidence affect confidence?
4. Empirical evidence: What do Sprint Goal outcomes, cycle time, defects, and stakeholder feedback indicate?
5. Scrum effectiveness: Which events and artifacts enabled inspection and adaptation? Which became ceremonial?
6. Team collaboration: How were decisions, conflict, workload, and inclusion handled?
7. Limitations and validity: What data was missing, biased, too small, or affected by student-project conditions?
8. Improvement plan: What should the team change in its next Sprint or project, and what evidence would show improvement?

Critical evaluation requires balanced judgement. For example, a high completion ratio may coexist with weak user value, while a lower ratio may reflect responsible discovery of a major assumption. Students should distinguish observation from interpretation and interpretation from recommendation.

12. Challenges, Governance, and Contemporary Practice

Common challenges include overloaded Product Owners, unclear authority, excessive work in progress, optimistic forecasts, technical debt, weak automated testing, and ceremonies treated as attendance requirements. These are addressed through explicit accountabilities, small vertical slices, visible impediments, continuous integration, and evidence-based review.

Governance concerns include privacy, accessibility, intellectual property, licensing, authentication, auditability, and responsible handling of user feedback. If AI tools are used for code, design, testing, or documentation, the team remains accountable for reviewing outputs. AI-generated code may contain security defects, licensing concerns, fabricated explanations, or unsuitable dependencies. Teams should record significant AI assistance where institutional policy requires it, verify generated material, and never upload confidential personal data or credentials.

Contemporary Scrum practice increasingly combines Scrum with continuous integration, automated quality checks, product analytics, and user research. These practices can strengthen delivery, but tools do not create agility. The essential question remains whether the team is delivering usable value, inspecting meaningful evidence, and adapting intelligently.

Chapter Summary

An applied Scrum product project integrates discovery, Product Goal formation, backlog management, Sprint Planning, full-stack engineering, review, retrospective improvement, and critical evaluation. Scrum’s empirical character depends on transparent artifacts, regular inspection, and adaptation. A well-formed increment crosses the necessary application layers and satisfies a shared Definition of Done covering quality, testing, integration, security, accessibility, documentation, and deployability. The DoD is not a Product Owner acceptance gate; Product Owner and stakeholder feedback influence product decisions separately. Sprint Reviews inspect the product with stakeholders, while Retrospectives inspect teamwork and process. Metrics can support learning when definitions and limitations are explicit, but they must not become individual productivity scores. Professional evidence includes templates, team records, technical proof, metric reports, review and retrospective records, and a structured final critical evaluation.

Key Terms

Product Goal: The future state that gives the Scrum Team a shared purpose.

Product Backlog: An ordered, evolving list of work needed to improve the product.

Sprint Goal: The objective and value focus for a Sprint.

Increment: A usable, integrated step toward the Product Goal.

Definition of Done: The shared quality standard required for work to be considered complete and usable.

Acceptance Criteria: Conditions describing expected behaviour or outcomes for a backlog item.

Product Owner: The accountability for maximising product value and managing the Product Backlog.

Scrum Master: The accountability for helping establish Scrum and improving Scrum effectiveness.

Developer: A Scrum Team member accountable for creating the increment.

Empiricism: Decision-making based on transparency, inspection, and adaptation.

Backlog Refinement: Ongoing clarification, splitting, estimation, and ordering of backlog items.

Sprint Review: An event for inspecting the increment with stakeholders and adapting future work.

Sprint Retrospective: An event for improving quality and effectiveness of the team.

Throughput: The number of completed items in a stated period.

Cycle Time: Elapsed time from a defined start point to a defined completion point.

Escaped Defect: A defect discovered after the team considered work complete or after deployment.

Vertical Slice: A small capability implemented across the relevant technical layers.

Technical Debt: Future cost created by choosing a quick or incomplete technical solution.

Psychological Safety: A team condition in which people can raise concerns and ideas without fear of humiliation or punishment.

Review Questions

Short Answer Questions

1. What are the three pillars of empiricism in Scrum?
2. Distinguish a Product Goal from a Sprint Goal.
3. Why should a full-stack team use vertical slices?
4. Give two examples of evidence that may be included in a project portfolio.
5. Why should velocity not be used as an individual performance score?

Long Answer Questions

1. Explain how a team can move from user discovery to an ordered Product Backlog. Include the role of assumptions, acceptance criteria, and refinement.
2. Design and justify a Definition of Done for a full-stack student project. Explain why Product Owner acceptance should not be included as a DoD condition.
3. Describe how a team should participate in a Sprint Review and a Sprint Retrospective. Compare their purposes, participants, evidence, and outputs.
4. Explain how security, accessibility, privacy, testing, and deployment should be integrated into full-stack Scrum work.
5. Critically evaluate the risks of using completion ratios, cycle time, velocity, and defect counts as project metrics.

Analytical / Application Questions

1. A team completes 5 of 7 planned items but achieves its Sprint Goal. Analyse what additional evidence is needed before judging the Sprint successful.
2. A registration feature passes its acceptance criteria but has no automated tests and cannot be deployed from the main branch. Decide whether it is Done and justify the decision using a DoD.
3. A team’s cycle times for four items are 1, 2, 3, and 10 working days. Calculate the mean and explain why the mean alone may give an incomplete picture of flow.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the Definition of Done?

A. A list of tasks approved by the Product Owner before release

B. A shared quality standard for considering an increment complete and usable

C. A forecast of all features required by the end of the project

D. A record of stakeholder opinions about the product

Correct Answer: B. A shared quality standard for considering an increment complete and usable

Question 2

What is the primary purpose of a Sprint Review?

A. To assign individual performance ratings

B. To inspect the increment with stakeholders and adapt future work

C. To approve the team’s timesheets

D. To replace Product Backlog refinement

Correct Answer: B. To inspect the increment with stakeholders and adapt future work

Question 3

What is the primary purpose of a Sprint Retrospective?

A. To improve the team’s way of working and effectiveness

B. To demonstrate every line of source code to customers

C. To create the Product Goal for the first time

D. To formally accept every backlog item

Correct Answer: A. To improve the team’s way of working and effectiveness

Question 4

A team completes 6 of 8 planned items. What is its completion ratio?

A. 25%

B. 60%

C. 75%

D. 80%

Correct Answer: C. 75%

Question 5

Which item is most appropriate for a full-stack Definition of Done?

A. The Product Owner attended the Daily Scrum

B. The feature is the largest item in the Sprint

C. The code is integrated, tested, reviewed, and deployable

D. Every requested future feature is documented

Correct Answer: C. The code is integrated, tested, reviewed, and deployable

Question 6

Who makes the forecast of how much work can be selected for a Sprint?

A. The Developers

B. External stakeholders בלבד

C. The Scrum Master alone

D. The university administrator

Correct Answer: A. The Developers

Question 7

Three items have cycle times of 2, 4, and 6 working days. What is the mean cycle time?

A. 3 working days

B. 4 working days

C. 5 working days

D. 12 working days

Correct Answer: B. 4 working days

Question 8

Which practice best supports empirical Scrum?

A. Hiding unfinished work until the final demonstration

B. Changing the DoD for each individual item without discussion

C. Making work and quality evidence visible, then adapting from inspection

D. Ranking individuals by story points completed

Correct Answer: C. Making work and quality evidence visible, then adapting from inspection

Question 9

What is a vertical slice?

A. A complete product plan written before discovery

B. A capability implemented across the relevant technical layers

C. A database-only prototype with no user interaction

D. A list of unresolved retrospective complaints

Correct Answer: B. A capability implemented across the relevant technical layers

Question 10

A feature satisfies its acceptance criteria but cannot be deployed and has no required tests. Under the sample DoD, what is the correct conclusion?

A. It is Done because acceptance criteria always override the DoD

B. It is Done if the Product Owner says so

C. It is not Done because the shared quality conditions are unmet

D. It is automatically removed from the Product Backlog

Correct Answer: C. It is not Done because the shared quality conditions are unmet