Studio Session: weekly DS3 ritual

Three 40-minute sessions inside the 120-minute class block

Author
Affiliation

Lucas P. Cordova, Ph.D.

Willamette University

Published

May 25, 2026

Abstract

The Studio Session is the weekly DS3 ritual that runs every class meeting from week 4 to week 13. The 120-minute class block hosts three sequential 40-minute Studio Sessions. Each of the 21 capstone projects is assigned to exactly one session, and every individual is a stakeholder on exactly two projects, one in each session other than their own project’s session.

Design constraints

The Studio Session has to satisfy four hard constraints:

  1. Fit inside the 120-minute class block. Three 40-minute Studio Sessions run back to back inside one class meeting, with short transitions between them.
  2. Respect dual-role workload. Every student is also an Owner on their own project. They cannot spend an hour per stakeholder project per week.
  3. Produce written artifacts. Verbal feedback evaporates; written Briefs and Critiques become part of the audit trail and the grade.
  4. Coexist with the academic calendar. Some iterations finish in three days, some in two weeks. The session runs anyway.

The new three-session structure replaces the previous odd/even rotation. Each individual now attends both of their stakeholder projects in person every week, because their two stakeholder assignments are placed in the two sessions other than their own project’s session.

Weekly cadence at a glance

The Studio Brief and Studio Critique submission times are set per studio in the Studio Charter working agreements section. The Sunday-before-class default works for a Monday meeting.

In-class schedule (120 minutes)

The 120-minute class block is divided into three back-to-back Studio Sessions. Each session is 40 minutes long. Inside a single Studio Session, every project assigned to that session runs the same 40-minute agenda in parallel at separate tables; owners are at their table the whole 40 minutes and their two or three peer stakeholder POs join them for the full slot.

Block Time (in a 8:00 - 10:00 PM slot) What happens
Studio Session 1 8:00 - 8:40 All projects assigned to Session 1 run the 40-minute agenda in parallel at their tables; stakeholders for those projects attend.
Transition 8:40 Stakeholders move to the next project they support; I circulate.
Studio Session 2 8:40 - 9:20 All projects assigned to Session 2 run the 40-minute agenda in parallel; new stakeholders attend.
Transition 9:20 Final stakeholder shift; I check in.
Studio Session 3 9:20 - 10:00 All projects assigned to Session 3 run the 40-minute agenda.

Which projects sit in which session is fixed for the term and published on the Peer Stakeholder PO lookup page (the Studio Session column). The assignment was chosen so that each session contains projects from across the major domains, and so every individual’s two stakeholder projects fall into the two sessions that are not their own.

40-minute in-session agenda

Inside each 40-minute Studio Session, every active project follows the same agenda at its own table. Times below are typical, not sacred. I may shorten or lengthen any phase based on what a particular studio needs.

Phase Time What happens
1. Owner standup 5 min Owner team does a yesterday / today / blockers standup at the board (and posts it in #<project>-standup on Discord). Solo owners self-standup in writing and post to the repo before the session starts.
2. Studio Critique discussion 10 min Peer POs walk the owner team through their written critique of last week’s delivery (committed to the repo and linked in #<project>-studio). Owner team listens, asks clarifying questions, captures items they will integrate.
3. Studio Brief discussion 10 min Peer POs walk through their written brief for the next iteration. Owner team negotiates scope and timing, marks each item as adopted, deferred, or declined with a reason.
4. Backlog refinement and board walk 10 min Owner team opens the Iterative Development board and walks it left to right with peer PO input. For each card: confirm it is in the right column for the work currently happening (Create / Observe / Analyze), advance any card whose phase is finished, and refine the top of Backlog so each candidate PBI passes the Definition of Ready (hypothesis, Create / Observe / Analyze triple, milestone tag, size). Pull new cards out of Backlog only up to the WIP cap (owners + 1 in flight).
5. Instructor sync and commitment 5 min I visit the table, scan the board column by column, and call out anything stuck or in the wrong column. Owner team logs its iteration commitment to the repo, including which Studio Brief items it adopted and which PBIs are now sitting in Create, Observe, or Analyze.

The ritual is deliberately heavy on written Briefs and Critiques during in-class time. The point of the session is not to write them in the room. The point is to discuss what was already written before class, so peer POs cannot ghost the ritual and so owners cannot wave away feedback.

Between-class cadence

The written cadence runs on each project’s GitHub repo and is mirrored to the project’s Discord category so peer POs can engage asynchronously:

  • Iteration Review in the repo README.md by the Sunday before the next class. Captures completed PBIs, board snapshot, and what was created / observed / analyzed. Linked in #<project>-general.
  • Retrospective at milestone boundaries (after W4, W7, W10, W12, W14). Owner team posts what to change in the process. Peer POs comment.
  • Studio Brief by each peer PO, committed to studio/briefs/W<NN>-<peer-name>.md in the owner team’s repo by the Sunday default, then linked in the project’s #<project>-studio Discord channel.
  • Studio Critique by each peer PO, committed to studio/critiques/W<NN>-<peer-name>.md in the owner team’s repo by the Sunday default, then linked in #<project>-studio.
  • Blockers flagged in #<project>-blockers between classes get my response there or in the next Studio Session, whichever is faster.

Artifact templates

Studio Brief (peer PO to owner team, before class)

Stored in the owner team’s repo at studio/briefs/W<NN>-<peer-name>.md. About one page.

# Studio Brief, week <NN>, from <peer PO name> to <owner team>

**Filed:** <date and time>
**For iteration starting:** <date>

## What we want you to consider for next iteration
1. <requirement, question, or risk> -- why it matters: <one sentence>
2. ...

## Why now
<one or two sentences linking these items to the project's current milestone tag>

## What we are not asking for
<one sentence so the owner team is not surprised>

Studio Critique (peer PO to owner team, before class)

Stored at studio/critiques/W<NN>-<peer-name>.md. About one page.

# Studio Critique, week <NN>, from <peer PO name> to <owner team>

**Filed:** <date and time>
**Reviewing iteration ending:** <date>

## What you delivered
<one paragraph summary of what we saw in the iteration review and board snapshot>

## Against last week's Studio Brief
- Item 1 from brief: <adopted / deferred / declined / partial>
- Item 2 from brief: ...

## Against the Charter
- Are you still moving toward your Vision and Mission? <yes / no / drifting because ...>
- Are you on track for the next milestone tag (<M1, M2, M3, M4, M5>)? <yes / no / at risk because ...>

## Two strengths
- ...
- ...

## Two specific revision suggestions
- ...
- ...

Iteration Review (owner team, in README, before class)

## Iteration Review, week <NN>

### Completed PBIs
- PBI-### <title> -- Create: <link>, Observe: <result>, Analyze: <decision>
- ...

### In-flight (still running across the boundary)
- ...

### Stakeholder response log
- Studio Brief from <peer PO name>: items adopted = ..., deferred = ..., declined (with reason) = ...
- Studio Brief from <peer PO name>: ...

### Plan for next iteration
- Top PBIs (with milestone tags): ...

### Risks and impediments
- ...

Participation expectations and how DS3 stays fair

The dual workload only works if everyone files briefs and critiques. DS3 makes this enforceable:

  • Every brief and critique is a committed file with a timestamp. Missed weeks are visible.
  • Owner teams must log adoption status for every Studio Brief item. Quiet ignoring is not allowed.
  • I audit the studio/ folder during each Studio Session’s instructor sync.
  • Late or missing briefs and critiques count against the Stakeholder participation component of the course grade, which is its own top-level bucket worth 15% of the final grade. The bucket has a published four-point rubric and a participation floor: missing 4 or more Briefs or Critiques over the term caps this component at 50% of its possible points. Full rubric and grading rules live on the syllabus; supporting context on the project methodology page.

What “substantive” feedback looks like is defined on the Peer Stakeholder PO lookup page: specific, kind, and actionable, tied to a visible artifact rather than a personality.

Milestone weeks

On milestone weeks (W4 proposal, W7 data summary, W10 poster draft, W12 write-up draft, W14 final), the in-session agenda compresses to make room for the milestone deliverable itself. A reasonable compression of the 40-minute slot:

Phase Compressed time
Owner standup 3 min
Studio Critique 7 min (focus only on milestone-tagged items)
Studio Brief 5 min (next milestone tag only)
Milestone artifact work 20 min
Instructor sync and commitment 5 min

Written Briefs and Critiques are still required that week.

References

  1. DATA 510 Data Science Studio Scrum (DS3) framework.
  2. DATA 510 Studio Charter.
  3. Saltz, J. S., Hotz, N., and Sutherland, A. (2022). Achieving Lean Data Science Agility Via Data Driven Scrum. HICSS 55. https://hdl.handle.net/10125/80218
  4. Data Science Process Alliance. Data Driven Scrum. https://www.datascience-pm.com/data-driven-scrum/
  5. Schwaber, K., and Sutherland, J. The Scrum Guide. https://scrumguides.org/
  6. Anderson, D. J., and Carmichael, A. The Kanban Guide. https://kanbanguide.org/