Project methodology
What the DATA 510 capstone is, how teams form, what gets graded
Abstract
This is the starting point for understanding the DATA 510 capstone: what the deliverable is, the five pillars it draws from, how teams are formed, how studios are assigned, and how the milestone calendar maps onto the DS3 operating framework. Read this page first, then dive into the operational subpages (Studio Charter, Studio Session, Peer Stakeholder PO lookup) for the week-to-week mechanics.
Capstone overview
The DATA 510 capstone is a semester-long culminating project in which you propose, build, evaluate, and communicate a consequential data science outcome. It is designed to draw together what you have practiced across the MS program, not as a checklist of disconnected homework, but as one coherent story you can defend to peers, faculty, and industry guests at the end-of-term poster session.
A strong capstone integrates five pillars of your coursework:
- Data engineering. Sourcing, cleaning, storing, versioning, and automating data so analyses are reproducible and auditable.
- Analytics and machine learning. Appropriate modeling or inference, validation discipline, and honest limits of what the data can support.
- Visualization and communication. Graphics and narrative that make findings legible to technical and non-technical audiences.
- Ethics and responsible use. Privacy, consent, fairness, transparency, and proportionality in how data are collected, shared, and interpreted.
- Statistics and research design. Clear questions, baselines, and evidence that match the claim you want to make.
Exactly how each pillar shows up depends on your question, but the proposal and milestones must make the integration explicit. Silo projects that read as “only a dashboard” or “only a model notebook” without engineering, ethics, or communication will be pushed to deepen before approval.
Data sources must be selected and approved by me early in the term. See the course syllabus for policies, weights, and deadlines.
Team size and project formation
Solo or self-selected team of 2 to 3
You may complete the capstone individually or in a self-selected team of two or three students. Solo work is welcome when you already have a focused direction and do not want consensus overhead. Small teams are welcome when the problem genuinely benefits from parallel tracks and complementary skills.
Higher bar for multi-person teams
Projects that include two or three collaborators are expected to carry noticeably higher scope, risk, or surface area than a comparable solo project: more ambitious data integration, stronger evaluation, clearer division of labor, and commensurate documentation. During the Project Proposal milestone (M1, week 4), team projects are reviewed for fit. I must approve the proposed scope so that headcount matches workload and so milestones remain fair across the cohort.
If a team proposal reads as “the same solo scope with extra names on the title slide,” expect revision requests before the Studio Charter is approved.
Quick reference
| Dimension | Rule |
|---|---|
| Team size | Solo, or self-selected groups of 2 to 3 |
| Peer Stakeholder POs (assigned) | Two or three peer PO individuals from adjacent projects, drawn from the Peer Stakeholder PO lookup |
| Team scope approval | Evaluated at the proposal (M1); required for multi-person teams |
| Studio Session (assigned) | One of three (1, 2, 3); determines when your studio meets in class. See the Studio Session page for the in-class schedule. |
The studio (your project’s triad)
Every capstone is placed in a studio: your owner project plus the two or three peer Stakeholder PO individuals assigned to it. Peer POs are drawn from across the cohort to build a domain-matched product-ownership triad around your work, and you in turn serve as a peer PO on two adjacent projects yourself. This dual-role design is the mechanism by which every student experiences the receiving end of vague requirements and late deliverables, not just the producing end. The full design is described on the DS3 framework page; the assignments are published on the Peer Stakeholder PO lookup.
The studio is how we keep parallel capstones in sync without merging them into one mega-team. You remain responsible for your own backlog and deliverables, and you also act as a standing review panel for two partner projects through the weekly Studio Brief / Studio Critique loop described on the Studio Session page.
What good peer feedback looks like
- Ties comments to visible evidence (board column, README section, plot, schema sketch).
- Separates exploratory curiosity from blocking concerns (e.g., “interesting subgroup split” vs “join will double-count users”).
- Surfaces ethics and engineering risks early (consent, retention, PII, reproducibility, evaluation leakage).
- Specific, kind, and actionable; tied to an artifact rather than a personality.
How peer Stakeholder PO duties are graded
Peer Stakeholder PO duties carry a dedicated 15% of the course grade as a top-level component (see the syllabus grading section). Each week you owe a written Studio Brief and Studio Critique for each of the two projects you are a peer PO on, plus live participation in the in-class Studio Session.
A four-point rubric and a participation floor apply: missing 4 or more Briefs or Critiques over the term caps this component at 50% of its possible points. Full rules live in the syllabus. The audit trail is the timestamped commits in each owner team’s studio/briefs/ and studio/critiques/ folders, plus my own notes from the in-class Studio Sessions.
DS3, the operating framework
Starting week 3, this course runs on Data Science Studio Scrum (DS3), a capstone-tailored adaptation of Data-Driven Scrum (DDS). DS3 keeps the DDS operating model and adds:
- Triadic distributed product ownership (two or three peer PO individuals per project).
- A written weekly Studio Brief / Studio Critique loop.
- An academic cadence overlay that pins Iteration Reviews and standups to the class meeting, even though iterations themselves are capability-based and finish whenever the work finishes.
- A single-session Studio Charter inception in week 3.
- Milestone-tagged backlog items (
M1-proposal,M2-data-summary,M3-poster-draft,M4-writeup-draft,M5-final) so process never drifts away from grades.
The full operational reference (roles, artifacts, the Iterative Development board, WIP rules, Discord channels) lives on the DS3 framework page. Read it after this page.
What DS3 (and DDS underneath it) optimize for
- Collaboration and communication. Boards and weekly Iteration Reviews make progress legible to teammates, peer POs, and to me.
- Empirical iteration. Short cycles of create, observe, analyze so the backlog reflects what you learned, not what you guessed in week one.
- Highest priority next. The backlog and refinement rituals force a steady answer to “what is the most valuable thing to do next given current evidence?”
Core artifacts you maintain
- Product Backlog Item (PBI). A unit of work framed as a hypothesis or user story, with a Create / Observe / Analyze triple, a milestone tag, and a size.
- Backlog. Prioritized list of PBIs.
- GitHub Projects board (Iterative Development). Five status columns, one PBI per card.
- Iteration Review. Weekly section in your repo
README.mdcapturing what was completed, observed, analyzed, and planned next. - Studio Brief and Studio Critique. New in DS3: peer POs file these as committed markdown files in the owner team’s repo each week.
In-class rituals
Standups and backlog refinement are completed during the scheduled class meeting and are expected to be finished by the end of that session, including the in-class Studio Brief and Studio Critique discussions. Written follow-ups (Iteration Reviews in README.md, Studio Briefs and Critiques in studio/) post to your project repo on the schedule your charter sets. The exact 40-minute agenda is on the Studio Session page.
Milestones at a glance
Formal graded artifacts follow the syllabus and Canvas (weights, rubrics, and due dates live there). DS3 does not replace those milestones; it is how you steer week to week toward them with visible process. Each milestone is also a milestone tag in your backlog, so every PBI you pull in week 5 is tagged with the milestone it serves.
| Tag | Milestone | Week | Role in the capstone |
|---|---|---|---|
| (none, week 3) | Studio Charter committed | 3 | Vision, mission, context, success criteria, working agreements, Response SLAs, DoR/DoD; seeded backlog with milestone-tagged PBIs. See Studio Charter. |
M1-proposal |
Project Proposal | 4 | Locks research direction, data plan, ethics notes, methods, and team scope. The Charter is committed in week 3; the proposal extends it into a written roadmap due in week 4. |
M2-data-summary |
Data Summary | 7 | Shows data are real, documented, and ready for analysis. Pipelines or pulls are complete enough that ingestion is no longer a weekly fire. |
M3-poster-draft |
Poster Rough Draft | 10 | Forces an end-to-end story on the wall early enough to critique visuals and claims. |
M4-writeup-draft |
Write-Up Rough Draft | 12 | Integrates methods, results, and limitations in publication-style prose. |
M5-final |
Final Poster Presentation and Write-Up | 14 | Public defense and archival write-up linked from your portfolio site. |
infra |
(ongoing) | – | Engineering work that serves multiple milestones. |
ethics |
(ongoing) | – | Consent, fairness, retention, governance work. |
The exact Canvas due dates, weights, and submission instructions are on the course syllabus and on each milestone’s Canvas assignment page.
General expectations
- Repositories and write-ups should be citable and reproducible enough that a peer could reorient mid-semester by reading
README.mdandCHARTER.mdalone. - Iteration is expected: proposals evolve when data talk back, but changes should be documented in your Iteration Reviews and Charter amendments.
- Teams are jointly responsible for deliverables; peer POs are not substitutes for your own teammates.
- When in doubt, Canvas and the syllabus supersede any secondary summary page (including this one).