What a capstone is and how this one works

The capstone is the last course in the computing science program and the one that looks most like professional work. For one term a small team builds and ships a real piece of software for a real client, from the first conversation about the problem to a final demonstration and handover. You will not learn many new algorithms here. Instead you will apply what earlier courses taught, and discover which parts of it matter when a deadline, a client and four teammates are involved. CMPUT-301 gave you software process, requirements, design, version control and testing. CMPUT-401 gave you product discovery, prioritization, client contracts and operating a product. CMPUT-404 taught full-stack web development, CMPUT-421 human-centred design and accessibility, CMPUT-291 databases, CMPUT-331 security and CMPUT-450 the realities of distributed systems. This course points back to all of them rather than repeating them.

Capstone projects exist because employers, accreditation bodies and graduates all report the same gap: students can solve well-specified problems alone, but have less practice with vague problems, other people and long time scales. Real projects are underspecified, the client changes their mind, a teammate gets sick, a library breaks, and the thing you built must keep working after you leave. The capstone gives you a controlled place to meet those problems while a supervisor is still there to help. It is also the course most often discussed in job interviews, because it is the one piece of evidence that you can deliver working software with a team.

The project we will follow

Every lesson follows one invented team through one invented project, so that each technique is shown in context. Team Relay has five students: Priya Natarajan, Marcus Oyelaran, Sofia Reyes, Ethan Kowalski and Lin Zhao. Their client is the Riverbend Food Rescue Co-op, an invented non-profit in Winnipeg that collects surplus food from grocery stores, bakeries and restaurants and delivers it to shelters and community kitchens, using about 140 volunteer drivers. Today the co-op schedules pickups with a shared spreadsheet, a group chat and many phone calls by its volunteer coordinator, Grace Delorme. Food is wasted when a driver cancels late and nobody notices, and Grace spends about 15 hours a week on scheduling. The team will build RescueRoute, a web application for scheduling volunteers and tracking pickups. Their faculty supervisor is Dr. Helen Okafor.

Community clients are a common choice for capstones. The problems are real, the stakes are moderate, the client is usually grateful for help, and the work has visible social value. They also carry particular responsibilities. A non-profit has little money and no IT staff, so whatever the team builds must be cheap to run and simple to maintain after the students graduate. Volunteers and the people the co-op serves may be vulnerable, so privacy matters. And the client's time is precious: a volunteer coordinator who spends three hours a week answering student questions is not scheduling pickups. We will come back to each of these points.

How the term is organized

The term runs thirteen weeks, and the figure shows its shape. The first three weeks are discovery: the team forms, writes a charter, meets the client and turns what it learns into a proposal. Weeks 4 and 5 turn the proposal into requirements and an architecture, which a panel of instructors reviews. Weeks 6 to 12 are four sprints of roughly two weeks each, with a demonstration to the client at the end of each sprint. Week 13 is for the final demonstration, the report and handover. The schedule front-loads thinking on purpose. Teams that start coding in week 1 usually build the wrong thing quickly; teams that spend three weeks understanding the problem build less but build what the client needs.

Each phase has a deliverable that is marked, so that feedback arrives early and often. The proposal is marked in week 3, the design review in week 5, each sprint's increment at its demo, and the product, report and individual reflections at the end. The marking scheme below rewards evidence of process as well as the final product, because a capstone is assessed on how you worked as much as on what you shipped. A team that ships a modest product with a clean repository, real tests, honest retrospectives and a satisfied client will do better than a team that ships an ambitious product nobody else can run.

# How the capstone mark is built: course components, weights and Team Relay's scores.
components = [
    # (component, weight %, team or individual, Team Relay's score out of 100)
    ("Project proposal and client agreement", 10, "team", 84),
    ("Architecture and design review",         10, "team", 78),
    ("Sprint deliverables (4 sprints)",        30, "team", 81),
    ("Testing and quality evidence",           10, "team", 88),
    ("Final product and demonstration",        20, "team", 86),
    ("Final report",                           10, "team", 80),
    ("Reflection and peer evaluation",         10, "individual", None),
]
assert sum(w for _, w, _, _ in components) == 100
team_part = sum(w * s for _, w, kind, s in components if kind == "team") / 100
print(f"team-earned marks: {team_part:.1f} of 90")
# Individual component differs per student (reflection score out of 100).
reflection = {"Priya": 90, "Marcus": 85, "Sofia": 92, "Ethan": 74, "Lin": 88}
for name, r in reflection.items():
    total = team_part + 10 * r / 100
    print(f"{name:7} reflection {r:3d} -> course mark {total:5.1f}")

team-earned marks: 74.5 of 90
Priya   reflection  90 -> course mark  83.5
Marcus  reflection  85 -> course mark  83.0
Sofia   reflection  92 -> course mark  83.7
Ethan   reflection  74 -> course mark  81.9
Lin     reflection  88 -> course mark  83.3

The shared mark is deliberate. Software is built by teams, and the incentive structure should reward helping teammates succeed rather than competing with them. The individual component, together with peer evaluation (lesson 7), protects against the opposite problem: a student who contributes little cannot ride on the team's grade without consequence. Your supervisor can also adjust an individual's share of the team mark when peer evaluations and repository evidence agree that contributions were very unequal. We will see how that adjustment is calculated in lesson 12.

Roles on a student team

Professional teams have specialists and a manager. A student team has neither, so it borrows lightweight roles that make responsibility clear without creating a hierarchy. A common set is a product and client lead, who owns the relationship with the client and the backlog; a technical lead, who owns architecture decisions and code review standards; and leads for front end, operations and quality. Roles are about ownership, not about doing all the work in that area. The quality lead does not write all the tests; she makes sure the team has a test strategy and that it is followed. Every member writes code, reviews code and talks to the client at some point.

Rotate some duties to spread learning and avoid single points of failure. Team Relay rotates who runs the weekly stand-up and who presents at each sprint demo, so that every member has presented to the client at least once by the end of term. They do not rotate the technical lead, because consistency in architecture decisions matters more than variety. Discuss roles openly in the first meeting, matching them to interests and to gaps people want to fill: a student who has never touched deployment might volunteer to pair with the operations lead rather than avoid it all term.

A responsibility matrix, often called a RACI matrix, records who does what for each major deliverable. For each deliverable, one person is accountable (A), meaning they own the outcome and sign it off; one or more are responsible (R), meaning they do the work; some are consulted (C) before decisions; and others are kept informed (I). The two rules that matter most are that every deliverable has exactly one accountable person and at least one responsible person. A deliverable with two accountable people tends to be finished by neither, because each assumes the other is on it.

# Team Relay's responsibility matrix (RACI) for the main capstone deliverables.
# R = responsible (does the work), A = accountable (one owner who signs off),
# C = consulted before, I = informed after.
team = ["Priya", "Marcus", "Sofia", "Ethan", "Lin"]
roles = {
    "Priya": "product and client lead",
    "Marcus": "technical lead, back end",
    "Sofia": "front end and accessibility",
    "Ethan": "DevOps and data",
    "Lin": "quality and documentation",
}
raci = {
    "Project proposal":         {"Priya": "A", "Marcus": "R", "Sofia": "C", "Ethan": "C", "Lin": "R"},
    "Architecture review":      {"Priya": "C", "Marcus": "A", "Sofia": "R", "Ethan": "R", "Lin": "I"},
    "CI/CD pipeline":           {"Priya": "I", "Marcus": "C", "Sofia": "I", "Ethan": "A", "Lin": "R"},
    "Accessibility audit":      {"Priya": "I", "Marcus": "I", "Sofia": "A", "Ethan": "I", "Lin": "R"},
    "Test strategy":            {"Priya": "C", "Marcus": "R", "Sofia": "R", "Ethan": "C", "Lin": "A"},
    "Client demo, sprint 2":    {"Priya": "A", "Marcus": "R", "Sofia": "R", "Ethan": "I", "Lin": "C"},
    "Handover package":         {"Priya": "R", "Marcus": "R", "Sofia": "C", "Ethan": "R", "Lin": "A"},
    "Final report":             {"Priya": "R", "Marcus": "R", "Sofia": "R", "Ethan": "R", "Lin": "A"},
}
print(f"{'Deliverable':26}" + "".join(f"{p:>8}" for p in team))
for task, row in raci.items():
    print(f"{task:26}" + "".join(f"{row[p]:>8}" for p in team))

# Checks a good RACI must pass: exactly one A per row, at least one R per row,
# and no person who is accountable for too much.
problems = []
for task, row in raci.items():
    letters = list(row.values())
    if letters.count("A") != 1:
        problems.append(f"{task}: needs exactly one A, has {letters.count('A')}")
    if "R" not in letters:
        problems.append(f"{task}: nobody is responsible")
load = {p: sum(1 for row in raci.values() if row[p] == "A") for p in team}
work = {p: sum(1 for row in raci.values() if row[p] == "R") for p in team}
print()
for p in team:
    print(f"{p:7} ({roles[p]}): accountable for {load[p]}, responsible for {work[p]}")
print("problems:", problems or "none")

Deliverable                  Priya  Marcus   Sofia   Ethan     Lin
Project proposal                 A       R       C       C       R
Architecture review              C       A       R       R       I
CI/CD pipeline                   I       C       I       A       R
Accessibility audit              I       I       A       I       R
Test strategy                    C       R       R       C       A
Client demo, sprint 2            A       R       R       I       C
Handover package                 R       R       C       R       A
Final report                     R       R       R       R       A

Priya   (product and client lead): accountable for 2, responsible for 2
Marcus  (technical lead, back end): accountable for 1, responsible for 5
Sofia   (front end and accessibility): accountable for 1, responsible for 4
Ethan   (DevOps and data): accountable for 1, responsible for 3
Lin     (quality and documentation): accountable for 3, responsible for 3
problems: none

The team charter

A team charter is a short document, written and signed in the first week, that records how the team will work. It is cheap insurance against the most common capstone failures, which are not technical. Teams rarely fail because they cannot build a web application. They fail because two members have different ideas of what 'done' means, because one person stops answering messages, because decisions are relitigated every meeting, or because nobody knows what to do when a deadline slips. The charter does not prevent these problems, but it means the team has already agreed what to do when they happen, before anyone is upset.

Write the charter together, not by one person while others watch, and keep it short enough that people will read it: one or two pages. The definition of done is the most important line. Team Relay's says that a feature is done only when it has been reviewed by a teammate, its tests pass in continuous integration, it is deployed to the staging environment, its acceptance criteria have been checked and any relevant documentation is updated. Without such a definition, a feature that works on one person's laptop counts as done in their head and as unfinished in everyone else's, and sprint demos become exercises in surprise.

Revisit the charter at the end of each sprint during the retrospective. Working agreements are meant to change as the team learns. Team Relay discovered in sprint 1 that a 9:30 stand-up clashed with one member's Wednesday lab, and moved it; they discovered in sprint 2 that '24-hour replies' was not enough during the last three days of a sprint, and added a rule that pull requests waiting for review get priority over new work. Changing the charter is not a failure. Ignoring it is.

Working with a supervisor and a client

You have two kinds of stakeholder with different roles. Your supervisor is responsible for your learning and your assessment. They will ask hard questions about your process, help resolve team problems, and protect you from clients who ask for too much. Your client is responsible for the problem and, eventually, for the product. They decide what is valuable, answer questions about their work and accept or reject what you deliver. Keep them separate in your head. The supervisor is not your client's representative, and the client does not assign your grade, although supervisors usually ask clients how the project went.

Set expectations with the client in the first meeting. Explain that this is a student project with a fixed end date, that the team will deliver a working product of limited scope rather than everything they might want, and that someone at their organization will need to own the product afterwards. Agree how often you will meet, how to reach each other, and how quickly they can answer questions. Grace at the co-op agreed to a 45-minute meeting every second Thursday and to answer email within two working days, and named a backup contact for when she is away. That simple agreement saved the team weeks of waiting later in the term.

Tools the team uses

Choose tools in week 1 and keep them simple. Team Relay uses a shared Git repository with an issue tracker and pull requests, a team chat channel, a shared drive for client documents and meeting notes, and a free tier of a cloud hosting service for the staging site. Every client meeting has notes, written by a rotating note-taker and posted within a day, listing decisions, open questions and actions with owners. The notes become the evidence for the final report and the first place to look when someone asks 'when did we agree that?'. Avoid tool sprawl: three places to look for tasks means tasks fall between them.

Worked examples