Checkpoint 1 (CP1)
Phase 1 — Discovery · Due Week 7 · 5%
Overview
CP1 establishes your team's shared direction and evaluation thinking before serious building begins. It is a light deliverable by design — the goal is alignment, not exhaustive documentation. A focused, honest CP1 is more valuable than a polished but vague one.
What to Submit
1. Team Charter
Your team's agreed working norms. Include:
- How your team makes decisions when there is disagreement
- Your definition of done for a piece of work
- How your team communicates outside of class (frequency, channel, expectations)
2. Problem Statement with Evidence
A clear description of the collaboration pain point you are addressing. Include:
- What the problem is, and who specifically experiences this problem
- How you know the problem is real — you must have spoken with at least two people outside your team who actually experience this problem. Summarize what they told you.
- Why existing tools or approaches do not adequately solve it
3. Initial Interaction Design Sketch
A description or diagram of what your tool does. Include:
- What the tool does at a high level
- What the inputs and outputs are
- How two people would interact with it together
This does not have to be finalized. Your design could change across the semester.
4. Draft Evaluation Plan
How you will know whether your tool works. Include:
- Success definition: “We will know our tool works if...” — something observable and measurable
- Target users: who you will test with, and how you will access them
- Method: which evaluation approach (structured observation, pre/post survey, or brief interview) and roughly when you plan to conduct the evaluation
- Minimum evidence threshold: what would convince someone skeptical of your idea?
- Human-AI boundary (if your tool uses AI): what does the AI decide, and what does the human decide?
5. Repository Link
Confirm that your GitHub repository is set up with:
- Branch protection on main
- PR template in place (
.github/PULL_REQUEST_TEMPLATE.md) - DECISIONS.md started with at least one entry
- Current code steward recorded in DECISIONS.md
What Makes a Strong CP1
A strong CP1 is specific. “Teams have trouble communicating” is not a problem statement. “Engineering teams reviewing pull requests asynchronously lose context about why a decision was made, leading to redundant back-and-forth in code review” is a problem statement.
A strong CP1 is honest. If you are not sure about something — your target users, your evaluation method, whether your tool idea will work — say so. Uncertainty acknowledged now is easier to address than uncertainty hidden until CP2.
A strong CP1 is grounded in real evidence. The minimum is two conversations with real users. Teams that conduct more conversations at this stage consistently build better tools.
Rubric
CP1 is scored out of 100 points and counts for 5% of your course grade (team grade). The rubric rewards specific, honest, evidence-based work. It is not a measure of how polished the document looks.
| Section | Points |
|---|---|
| 1. Team charter | 15 |
| 2. Problem statement with evidence | 30 |
| 3. Initial interaction design sketch | 15 |
| 4. Draft evaluation plan | 30 |
| 5. Repository | 10 |
| Total | 100 |
1. Team Charter (15 points)
| Criterion | Pts | Full credit | Partial credit | No credit |
|---|---|---|---|---|
| Decisions when there is disagreement | 5 | A concrete process another team member could follow (who decides, what happens if the team cannot agree). | Stated but vague, such as “we discuss it” (2–3). | Missing (0). |
| Definition of done | 5 | Observable criteria that someone could check for a piece of work (for example reviewed, merged, DECISIONS.md updated). | Generic, such as “it works” (2–3). | Missing (0). |
| Communication outside class | 5 | Channel, how often, and what response time you expect from each other. | One of those three is missing (3). | Missing (0). |
2. Problem Statement with Evidence (30 points)
| Criterion | Pts | Full credit | Partial credit | No credit |
|---|---|---|---|---|
| Specificity | 10 | Names the exact problem and who experiences it, concrete enough that two readers picture the same situation. | Right area but still broad (5–7). | Generic, such as “teams have trouble communicating” (0–2). |
| Evidence from real users | 12 | At least two people outside your team who actually experience the problem; for each, who they are and what they told you, with specifics (not just “they agreed”). | Two conversations but the summaries are generic or show only agreement (7–9). Only one conversation (6). | No conversations, or only teammates (0–3). |
| Why existing tools do not solve it | 8 | Names at least one specific existing tool or approach and says what it fails to do for this problem, tied to what users told you. | Generic, such as “existing tools are not good enough” (3–5). | Missing (0–2). |
3. Initial Interaction Design Sketch (15 points)
| Criterion | Pts | Full credit | Partial credit | No credit |
|---|---|---|---|---|
| What the tool does | 5 | A clear description (text or diagram) that matches the problem you described. | Clear but not connected to the problem, or hard to follow (2–3). | Missing (0). |
| Inputs and outputs | 5 | Says what goes in and what comes out, specifically enough to build from. | Only one of the two, or too vague to build from (2–3). | Missing (0). |
| How two people interact with it | 5 | Shows what each person does and how work passes between them, not just “both can use it”. | Mentions two people but not how they interact (2–3). | Missing (0). |
4. Draft Evaluation Plan (30 points)
| Criterion | Pts | Full credit | Partial credit | No credit |
|---|---|---|---|---|
| Success definition | 8 | “We will know our tool works if...” is observable, measurable and about what happens for users, not only what the tool produces. | Observable but measures only output (such as “it generates summaries”), or not measurable (4–5). | Missing or not checkable (0–2). |
| Target users and access | 5 | Who you will test with (outside your team) and how you will reach them. | Who, but not how you will reach them (3). | Missing (0). |
| Method and timing | 5 | One approach named (structured observation, pre/post survey or brief interview) and roughly when it fits in the semester. | Method without timing, or timing that does not fit the semester (3). | Missing (0). |
| Minimum evidence threshold | 6 | States concretely what result would convince a skeptic (for example how many users, what change). | Stated but a skeptic would not be convinced (3–4). | Missing (0–1). |
| Human-AI boundary | 6 | If your tool uses AI: what the AI decides and what the human decides. If it does not: says so and why. Either earns full credit. | One side only, or an honest “not decided yet” that says how and when you will decide (3–4). | Missing (0–1). |
5. Repository (10 points)
| Criterion | Pts | Full credit | Partial credit | No credit |
|---|---|---|---|---|
| Branch protection on main | 3 | Enabled, and the TAs can see it. | — | Not enabled, or the link does not work (0). |
| PR template in place | 2 | At .github/PULL_REQUEST_TEMPLATE.md. |
— | Missing (0). |
| DECISIONS.md started | 3 | At least one real entry. | File exists but no real entry (1). | Missing (0). |
| Current code steward recorded | 2 | Recorded in DECISIONS.md. | — | Missing (0). |
Notes for Students
- Saying clearly that you are unsure about something (your users, your method, whether the idea will work) is never penalised. Claims that go beyond your evidence are.
- Your design may change later in the semester. Changing it is not penalised.
- Two conversations is the minimum for full marks on the evidence criterion. More conversations are valuable but do not earn extra points here.
- File format and naming are not graded unless they stop the TAs from reading your submission.
Submission
Submit one PDF or zip file per group to E3 under “CP1.” File name:
GroupXX_CP1.