Assessments¶

Grading overview¶

All assessments and due dates¶

Your course repo¶

All of your work lives in one private GitHub repository, your course repo, created in Lab 1 from the course starter template. It has a folder for each kind of work:

your-repo/
├── README.md           ← your project context and "Where the work lives"
├── CLAUDE.md           ← instructions Claude Code reads every session
├── .claude/skills/     ← /sprint-plan and /sprint-review
├── labs/               ← one folder per lab
├── sprints/            ← sprint plans and reviews
├── discovery/          ← interview notes (names removed) and synthesis
├── design/             ← flows, wireframes, usability test notes
├── specs/              ← user stories, acceptance criteria, feature specs
├── architecture/       ← diagrams and data model
└── app/                ← the code for your project (or a link to its own repo)

Add the instructor as a collaborator on the repo (Lab 1 shows you how). You submit by pasting a GitHub link into the matching Canvas assignment.

Labs¶

Eight labs, 25 points each. Each lab is started in class and finished on your own. The online session (Lab 5) is self-paced. Each lab page lists its steps and exactly what to turn in.

Submit the link to your labs/lab-N/ folder on Canvas.

The project¶

Across the five weeks you build one small information system for a real user: a person or organization you can actually talk to. Good sources:

• A campus club or organization you belong to (dues, sign-ups, equipment checkout, event check-in)
• A Gonzaga office or department process that runs on spreadsheets and email
• A small business you or your family work for in Spokane or at home
• A process you live with every week: a job, a team, a household, a volunteer role

The system should have a few screens, store data that matters to its user, and have at least one place where an AI model could help. Keep it small. A system that does one job well for one person is a better project than one that does ten jobs badly.

You may work alone or, with the instructor's approval, in a pair. Pairs share one repo and one project, and each partner writes their own sprint review and retro.

The project runs as two sprints. Every sprint is the same assignment: plan, build, review, and demo. What changes is the goal.

How every sprint works¶

Two Claude Code skills run each sprint. Both are in the .claude/skills/ folder of your course repo.

Day one: plan. Run /sprint-plan. It asks you what you are going to do and writes sprints/sprint-N-plan.md:

# Sprint N Plan

**Goal:** What will be true at the end of the sprint that is not true now?

**Why this:** Why is this the right next thing for your user?

**Done looks like:** How will you know the goal was met? Be specific enough
that someone else could check.

**Predicted difficulty:** 1 to 5.

Commit it, push it, and paste its GitHub link into that sprint's Plan assignment on Canvas. You can change the plan during the sprint: run /sprint-plan again and it adds a dated note saying what changed and why. A plan that changed with a note is fine. A plan that changed with no note is the thing to avoid.

During the sprint: build. Do the work, in your repo. Commit often.

Last day: review and demo.

1. Run /sprint-review. It reads your plan and your commits and writes a short report in sprints/sprint-N-review.md: what you did, when, and where you got stuck.
2. Answer its five retro questions in your own words:
   1. Did you hit the goal? Yes, partly, or no, and why.
   2. About how many hours did you spend on this sprint?
   3. If the plan changed, why?
   4. Actual difficulty, 1 to 5, and why it differed from your prediction.
   5. What will you change next sprint (or next project)?
3. Record a demo on Loom (free with a student account) showing the work, working. Set it to "Anyone with the link."
4. Submit your review link and your Loom link on Canvas.

The difficulty scale¶

Difficulty is not graded in either direction. Rate it honestly. Output is weighed by how hard the work actually was for you, so an ambitious goal you partly reach and account for in your retro can still earn full points.

Sprint 1¶

75 points | Assigned: Tue, Nov 10 | Plan due: Fri, Nov 13, 11:59 PM | Due: Mon, Nov 23, 11:59 PM

Goal of the sprint: pick a real user, find out what they actually need, write it down precisely, and ship a first version built from that spec.

Required output, in your course repo:

Sprint 2¶

125 points | Assigned: Tue, Nov 24 | Plan due: Tue, Dec 1, start of class | Final demo: Thu, Dec 10, in class | Due: Fri, Dec 11, 11:59 PM

Goal of the sprint: turn the first version into a real system: data that persists with access rules, a safe way to change it, and an AI feature that you have tested.

Required output:

Sprint 2 cannot be turned in late.

Confidential work¶

If your system is for an organization that does not want its data shared, use made-up data in your repo and say so in your README. Never commit real names, emails, phone numbers, student IDs, or passwords. Interview notes are committed with names removed, and recordings stay out of the repo.

Peer Assignments¶

Peer assignments teach you to give and receive useful feedback, a core professional skill for anyone who works on systems built by teams. You will be paired with a different classmate for each.

Peer Code Review¶

50 points | Assigned: Thu, Dec 3 | Due: Mon, Dec 7, 11:59 PM

Goal: read a classmate's codebase with an agent's help, run their system, and write a review that would help them improve it. Lab 7 practices the mechanics of a pull request review; this assignment applies them to a whole system.

Process:

1. Your partner adds you as a collaborator on their course repo.
2. Clone it, open it in VS Code, and start Claude Code inside it.
3. Run the three analysis prompts below and save each output in your own repo under peer-review/.
4. Run their deployed system as a real user.
5. Write the review using the peer code review template.

Prompt 1: "Analyze this project structure. List all directories and their purposes,
identify frontend vs backend files, and count total lines of code.
Save as peer-review-structure.md"

Prompt 2: "Trace the main user flow from UI to database.
What happens when a user performs the core action?
Save as peer-review-dataflow.md"

Prompt 3: "Identify the architecture pattern, code organization,
and any potential security concerns or code smells.
Save as peer-review-architecture.md"

The written review covers architecture observations, code quality, security (check for secret keys in the code and tables without row level security), and three specific, actionable suggestions. Read the AI's output critically: confirm at least one of its claims yourself in the code, and say which.

Turn in: commit the completed template to peer-review/review.md in your repo, send your partner the link, and submit the link on Canvas.

Peer Product Testing¶

50 points | In class: Thu, Dec 10 | Due: Fri, Dec 11, 11:59 PM

Goal: be a real test user for a classmate's system and give feedback they can act on. This is the usability test from Testing the Design, run on a finished system.

In class, after demos, you will be paired with a classmate. Open their deployed URL and:

1. Think out loud the entire time: what you see, what you expect, where you are confused.
2. Try to complete the core task: sign up, use the main feature, check that your data is still there after a refresh.
3. Try to break it: empty inputs, very long inputs, the back button, a second account.

Your partner watches and takes notes without helping. Then switch.

After class, record a 5-minute Loom of a second, solo pass through their system with think-aloud narration, ending with your summary:

• 3 things that worked well (be specific)
• 3 things you would improve, most important first
• Would the intended user use this system? Why or why not?

Submit the Loom link on Canvas and send it to your partner.