Studio Charter: single-session inception

DS3 inception, run on the Studio Session schedule in week 3

Author

Affiliation

Lucas P. Cordova, Ph.D.

Willamette University

Abstract

The Studio Charter is the DS3 inception process. It runs in week 3 on the same three-session, 40-minute studio schedule the rest of the term uses (W4 onward). Projects assigned to Studio Session 1 charter in the first 40 minutes; Session 2 projects charter in the next 40 minutes; Session 3 projects charter in the last 40 minutes. Each project’s chartering happens at its own table with its full triad in the room (owner team plus the two or three assigned peer stakeholder POs), in parallel with the other projects in the same session. The 40-minute slot finalizes pre-class drafts the owner team has already written into CHARTER.md and BACKLOG.md, locks in the Working Agreements and Response SLAs with the triad, and ends with a committed Charter and a seeded backlog.

How chartering fits the class block

Week 3 chartering uses the same Studio Session schedule the rest of the term runs on (W4 onward), so peer POs are at the table for inception in the same way they will be for every weekly Studio Session afterward.

Block	Time (8:00 - 10:00 PM)	Who is at which table
Charter Session 1	8:00 - 8:40	Projects assigned to Studio Session 1 charter in parallel at their tables. The two or three peer POs assigned to each of those projects join those tables for the full 40 minutes.
Transition	8:40 - 8:45	Stakeholders move to the next project they support.
Charter Session 2	8:45 - 9:25	Projects assigned to Studio Session 2 charter in parallel; new peer POs attend.
Transition	9:25 - 9:30	Final shift.
Charter Session 3	9:30 - 10:00	Projects assigned to Studio Session 3 charter in parallel; final set of peer POs attend.

Project-to-session assignments are fixed for the term and published on the Peer Stakeholder PO lookup page.

Pre-session checklist (owner team)

The 40-minute slot is not enough to write a Charter from scratch. The owner team does substantive pre-work async, then the in-class session is for finalizing with peer POs. By the time you sit down at your table, you should have:

Tooling ready

• One named Owner Product Lead (multi-person teams, this can be the same person or it can rotate; for solo owners, you are the lead).
• A GitHub repo for the project created by the Owner Product Lead from the DS3 template repo at https://github.com/LucasCordova/ds3template. On that page, click Use this template → Create a new repository; that gives you a working tree with README.md, CHARTER.md, BACKLOG.md, the studio/briefs/ and studio/critiques/ folders with templates, a .gitignore, and stubs for src/, notebooks/, data/, and deliverables/ already in place. Then:
  • Add LucasCordova as a collaborator with Admin access.
  • Add each of your two or three peer POs as collaborators with at least Triage access (they need to comment, open issues, and push studio briefs and critiques as commits or PRs).
• A GitHub Projects (v2) board linked to the repo, configured as an Iterative Development board with the five DS3 status columns: Backlog (prioritized PBIs), Create (building the artifact), Observe (running the measurement), Analyze (interpreting and writing up the decision), Done (linked in the next Iteration Review). Each column is a phase of work on a single PBI, not a work type. Bootstrap the board by copying my template at https://github.com/users/LucasCordova/projects/3 (three-dot menu → Make a copy → name it @Project Board); then in Project Settings link your repo as the Default repository and add LucasCordova (Admin) plus your peer POs (Read or Write) under Manage access. The full lifecycle, WIP limits, and the click-by-click bootstrap are described in Operational tooling > GitHub Projects board on the framework overview; read it before this session so you can pull, sequence, and refine PBIs without coaching.
• You have joined the class Discord via the invite. On the welcome screen, click the buttons that opt you into your own project’s category and each of your two peer projects’ categories. Pin the repo URL and Projects board URL in your #<project>-general channel.
• A laptop ready to fill in CHARTER.md live in the session.

Pre-class drafts in the repo

Push these to the repo before chartering so peer POs can read them ahead of time and arrive ready to stress-test, not draft from scratch:

• Vision and Mission drafts in CHARTER.md: one or two sentences each, even if rough. (See template below.)
• Context bullets in CHARTER.md: an honest first pass at users / affected parties, candidate data sources (with access status), constraints, and ethics risks. Bullets are fine.
• Success-criteria drafts in CHARTER.md: one measurable or demonstrable criterion per milestone (M1 W4, M2 W7, M3 W10, M4 W12, M5 W14). “We will have a working model” does not count; “ROC-AUC beats majority-class baseline by at least 0.05 on a held-out set” does.
• Working-agreements draft (internal) in CHARTER.md: how your owner team plans to sync, review code, and decide.
• Seeded backlog in BACKLOG.md and as GitHub issues on the Projects board’s Backlog column: 5 to 10 PBIs, each with a Create / Observe / Analyze triple and a milestone tag. Most should be M1-proposal-tagged.

The full GitHub and Discord setup is described in the DS3 framework overview. See the Peer Stakeholder PO lookup for which Studio Session your project belongs to.

In-session agenda (40 minutes)

Each project runs the same agenda at its own table during its assigned Studio Session. The slot is for finalizing drafts with peer POs, not drafting from scratch. Times below are typical, not sacred; I may shorten or lengthen any phase based on what a particular studio needs.

Phase	Time	Activity	Output
1. Anchor	5 min	Owner team reads aloud the W2 project direction snapshot and the pre-drafted Vision / Mission. Peer POs ask clarifying questions only, no critique yet.	Shared understanding of the starting picture.
2. Vision, Mission, Context check	8 min	Peer POs surface gaps in users, candidate data sources, constraints, and ethics risks. Owner team revises bullets in CHARTER.md live.	Sharpened Vision / Mission and a named risk list.
3. Success-criteria check	7 min	Peer POs sanity-check that each milestone criterion is measurable or demonstrable, achievable in the available time, and tied to the research question. Owner team revises criteria live.	Success criteria section finalized.
4. Working agreements + Response SLAs	12 min	Together fill the Response SLA table (the five signals; see template). Confirm Studio Brief and Studio Critique due times. Confirm the Definition of Ready and Definition of Done templates fit the project. Lock the priority-conflict resolution rule.	Working agreements, SLAs, and DoR / DoD sections.
5. Backlog walkthrough	6 min	Peer POs see the seeded backlog on the Projects board. They suggest 1 or 2 additions or reframings; owner team confirms each PBI has a Create / Observe / Analyze triple and a milestone tag. Issues that come up during the session are added as new PBIs in Backlog, not promised verbally.	Seeded BACKLOG.md and Backlog column refined.
6. Commit	2 min	Owner Product Lead commits CHARTER.md and BACKLOG.md in front of the table. The triad confirms the commit hash.	Charter committed, Canvas submission of the board URL after class.

The session ends with CHARTER.md and BACKLOG.md committed to the repo before the table breaks. The Owner Product Lead is responsible for submitting the project’s Projects board URL in Canvas after class so I know it is ready for review.

If a peer PO is missing from your slot (illness, conflict), file the issue in #blockers, charter without them, and schedule a 30-minute makeup with that peer PO before week 4. Their pre-class read of the drafts plus the makeup is enough; do not let the Charter set without their voice.

Roles inside the Studio Charter session

Who	Role in the session
Owner Product Lead	Drives the session. Holds the keyboard. Pushes for decisions when discussion stalls.
Owner Team members	Co-author every section; do not delegate to the lead.
Peer Stakeholder POs (two or three individuals)	Full participants. They are not observers. Their job is to surface what they care about as if they were the eventual customer or downstream user.
Me (Process Expert and Sponsor)	I float between the project tables that are active in the current Studio Session, coach on time-boxing each phase, flag when a section is too vague to be testable later, and act as the final arbiter on data approval.

Artifact templates

The following are paste-ready scaffolds. Owner teams should copy them into their repository, draft the first pass before their Charter Session slot (so peer POs can pre-read), and finalize them live with the triad during the 40-minute slot. Keep them in plain markdown so they diff cleanly in pull requests over the semester.

Response SLAs (Service Level Agreements)

A Service Level Agreement (SLA) is a written promise the triad makes about how fast each side responds when a specific signal arrives. SLAs are how we keep the brief / critique loop honest: without them a peer PO files a Studio Brief into a void and the owner team has no way to know whether anyone read it, and at the end of the term nobody can tell whether a missed acknowledgment was rude or just slow.

Every triad fills in the SLA table inside its CHARTER.md (under Working agreements (triad with peer POs)). Five signals must have an SLA before you commit the Charter:

1. Studio Brief filed by a peer PO. The owner team must acknowledge and give a first-pass adopt / defer / decline call for each item.
2. Studio Critique filed by a peer PO. The owner team must respond and capture any follow-up items into the backlog.
3. Iteration Review posted in README.md by the owner team. Both peer POs are expected to read it before filing the next Brief and Critique.
4. Blocker flagged in #blockers by the owner team. I respond, plus any tagged peer PO if the blocker is on them.
5. Clarifying question asked in #general. Whoever is tagged (or the owner team by default) replies.

For each row, write down by when and where (which channel, which file). The defaults in the template are reasonable starting points; adjust them to match how your triad actually works. The hard rule is that every row gets an answer before you commit CHARTER.md. A persistent pattern of missed SLAs is exactly the kind of evidence I look at when I score the Stakeholder participation component (15% of the course grade; see the syllabus and the project methodology page).

CHARTER.md template

# Studio Charter: <project name>

**Owner team:** <names>
**Owner Product Lead:** <name>
**Peer Stakeholder POs:** <names of your 2 or 3 peer PO individuals>
**Instructor / Sponsor:** Lucas Cordova (`LucasCordova` on GitHub)
**GitHub repo:** <link>
**GitHub Projects board:** <link>
**Discord category:** `#*`
**Studio Session:** <1, 2, or 3>
**Studio formed:** <date>

## Vision
One or two sentences. The world (or organization, or domain) if this project succeeds.

## Mission
One or two sentences. What the owner team will actually do this semester.

## Context
- **Users / affected parties:** who benefits, who is at risk, who might use the result.
- **Data sources (proposed):** named sources, access status, license/ethics notes.
- **Constraints:** time, compute, access, skills, scope.
- **Ethics risks:** consent, retention, PII, fairness, deployment risk.

## Success criteria by milestone
- **M1, proposal (W4):** <measurable criterion>
- **M2, data summary (W7):** <measurable criterion>
- **M3, poster rough draft (W10):** <measurable criterion>
- **M4, write-up rough draft (W12):** <measurable criterion>
- **M5, final write-up and poster (W14):** <measurable criterion>

## Working agreements (internal to owner team)
- **Sync rhythm:** <e.g., one async standup per weekday in #channel>
- **Code review:** <who reviews what, by when>
- **Decision rule:** <how the team decides when it disagrees>

## Working agreements (triad with peer POs)
- **Studio Brief due:** <example: by 5 pm the day before class, committed to `studio/briefs/W<NN>-<peer>.md` and linked in `#studio` on Discord>. If the owner team needs the peer POs to read or review something specific *before* the Studio Session (a data preview, model results, a draft figure), file the Brief earlier so the peer POs actually have time to do that homework. Otherwise the default is "before the Studio Session starts."
- **Studio Critique due:** <example: by the end of class for the in-person discussion, or at an agreed-upon time within one day after class (e.g., 5 pm the next day) if the peer PO needs extra time to draft a thoughtful write-up>.
- **Priority conflict resolution:** owner team integrates briefs in good faith; I arbitrate (as Process Expert) if peer POs and owner team disagree.

## Response SLAs (Service Level Agreements)

A **Service Level Agreement (SLA)** is a promise the triad makes about *how fast* each side responds to each named signal. Without an SLA, a peer PO files a Studio Brief into a void and the owner team has no way to know whether anyone read it. The defaults below are reasonable starting points; adjust each row to match how your triad actually works. The hard rule is that every row gets an answer before you commit `CHARTER.md`.

| When this signal arrives... | Who responds | By when |
|-----------------------------|--------------|---------|
| Peer PO files a **Studio Brief** (commits to `studio/briefs/...`, links in `#studio`) | Owner team | <e.g., acknowledge in `#studio` within 24 hours, including a first-pass adopt / defer / decline call for each item> |
| Peer PO files a **Studio Critique** | Owner team | <e.g., respond in `#studio` within 24 hours and capture follow-up items into the backlog> |
| Owner team posts an **Iteration Review** in `README.md` | Both peer POs | <e.g., read before filing the next Brief and Critique> |
| Owner team flags a **blocker** in `#blockers` (data approval, peer PO ghosting, scope conflict) | Me, plus any tagged peer PO | <e.g., I respond by the next Studio Session at the latest; faster if I am online> |
| Anyone asks a clarifying question in `#general` | Whoever is tagged (or the owner team by default) | <e.g., reply within 48 hours, even if the reply is "we will look at this next iteration"> |

## Definition of Ready (PBI)
A PBI is ready to be pulled out of `Backlog` and moved into `Create` when it has:
- A one-sentence hypothesis or user story
- A named **Create**, **Observe**, **Analyze** triple
- A milestone tag (`M1-proposal`, `M2-data-summary`, `M3-poster-draft`, `M4-writeup-draft`, `M5-final`, `infra`, `ethics`)
- A T-shirt size estimate (S, M, L, XL)
- WIP slack on the board: `Create + Observe + Analyze` is below the team's WIP cap (owners + 1)

## Definition of Done (PBI)
A PBI is done, and may be moved from `Analyze` into `Done`, when:
- The Create artifact is in the repo or linked from the issue
- The Observe results are recorded somewhere referenceable (notebook output, processed dataset, draft results section)
- The Analyze writeup names a next step (continue, pivot, kill, or decompose into new PBIs)
- A peer PO has either signed off in `#studio` or filed a Studio Critique covering it
- The card is linked under *Completed PBIs* in the next Iteration Review in `README.md`

Context map template (paste into CHARTER.md or docs/context-map.md)

BACKLOG.md template

# Backlog: <project name>

## Conventions
- Each item has: id, title, hypothesis, Create / Observe / Analyze, milestone tag, size.
- Items are ordered top to bottom by priority.

## Items

### PBI-001
- **Title:** Acquire and document <dataset>
- **Hypothesis:** <dataset> is accessible, license-compatible, and large enough to answer <RQ>.
- **Create:** ingestion script and README section describing schema.
- **Observe:** row counts, missingness, key uniqueness, distribution sanity checks.
- **Analyze:** decide whether the dataset survives feasibility, document in iteration review.
- **Tag:** `M1-proposal`
- **Size:** M

### PBI-002
- **Title:** ...
- **Hypothesis:** ...
- ...

Stakeholder alignment memo (one page, end of session)

# Stakeholder alignment memo: <project name>

## Why we exist
<two sentences from Vision and Mission>

## What we will deliver to you (peer POs) every week
- An Iteration Review in the README by <day/time>
- A summary of which Studio Brief items we adopted, deferred, or declined and why

## What we need from you every week
- A Studio Brief by <day/time> next class (next iteration's requirements, questions, risks)
- A Studio Critique by <day/time> next class (assessment of last week's delivery)

## How to reach us
- Discord category: `#general` for day-to-day, `#studio` for Briefs and Critiques, `#blockers` for impediments
- GitHub repo: <link>
- GitHub Projects board: <link>

What comes next

After the Studio Charter is committed:

1. The owner team uses the seeded backlog to write the Project Proposal (due end of W4).
2. The first weekly Studio Session runs at the next class meeting. See Studio Session for the agenda.
3. Peer POs begin filing Studio Briefs before each class.

References

1. DATA 510 Data Science Studio Scrum (DS3) framework.
2. DATA 510 Studio Session weekly ritual.
3. Caroli, P. (2018). Lean Inception: How to Align People and Build the Right Product. Editora Caroli.
4. Larsen, D., and Nies, A. (2016). Liftoff: Start and Sustain Successful Agile Teams (2nd ed.). Pragmatic Bookshelf.
5. 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