Week 7: Sprint 3 + Architecture + AI Agents

🚧Preview — this guide may still change before the session. Check back closer to your session time for the final version.

✅ Week 7 Checklist Track your progress — complete during and after this session

💬 Live Q&A Submit and upvote questions — Stefan answers live in Hour 3. Keep this open.

🔬 Validation Guide Full session recipe and Validation Report documentation guide

📊 Assessment Overview Grade breakdown, deadlines, and submission guide

⚓

Session anchor — write this down before you open your laptop

What matters most before Demo Day — and is that what your team is working on right now?

Take a pen and paper. Discuss as a team. Building more is not always the answer — strong validation evidence can matter more than a polished prototype. Return to this at the end of the session.

#	Mission	Time
0	📐 Architecture + Validation recap	First 30 min
1	🗣️ Standup + sprint planning	25 min
2	🔬 Validation — second round	Self-paced
3	🤖 AI agents — working smarter	Self-paced
4	⚙️ Build sprint	Remaining time

---

Mission 0 — Architecture + Validation recap

No direct questions to Stefan during this block. Post to the Live Q&A instead — Stefan works through the queue live in Hour 3.

Part A — System overview in your Technical Documentation

In Week 5 your team decided on a technical direction. Now you have been building for two weeks. This week: update the system overview section of your Technical Documentation to describe what you have actually built — not what you originally planned.

This is a conceptual description, not an engineering design. You are describing the main logical parts of your system and how they relate to each other. Engineering students can add technical depth from their major — but comprehensiveness of reasoning matters more than technical correctness, and it is not required for a top score.

Three questions to answer in plain language:

Question	What to write	MiaoLog example
What are the main parts?	Name the logical components — the user-facing app, where data is stored, any external service you use	”A mobile web app. A database that stores cats, feedings, and health notes. No server — the app talks directly to the database.”
How does data move?	Describe one user action from start to finish	”Volunteer opens the app → taps ‘Log feeding’ → form submits → database saves the record → the feeding appears in the list immediately.”
Why did you choose each tool?	One sentence per choice, in your own words — why, not just what	”We chose Supabase because it generates a full API from our database — the app can read and write data directly from the browser, no server code needed.”

Start from the MiaoLog example

The Week 5 guide has a worked example — stack decision, data model, and architecture explanation — using MiaoLog. Use it as a template for your own system overview. See the MiaoLog worked example →

What assessors look for: Reasoning, not technical sophistication. A team that writes “we chose X because Y” with a clear reason scores higher than one that lists tools without explanation — even if the tools listed are more technically impressive.

Template: ⬇ Technical Documentation — open the architecture section and update it today.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Part B — Validation: where you should be now

The validation process has four stages. Here is the map:

flowchart LR
    A["🔍 Stage 1\nProblem\nValidation"] --> B["💡 Stage 2\nConcept\nTesting"]
    B --> C["🧪 Stage 3\nUsability\nTesting"]
    C --> D["🔄 Stage 4\nClose\nthe Loop"]

    style A fill:#7c3aed,color:#fff,stroke:#a78bfa,stroke-width:2px
    style B fill:#b45309,color:#fff,stroke:#fbbf24,stroke-width:2px
    style C fill:#15803d,color:#fff,stroke:#4ade80,stroke-width:2px
    style D fill:#1d4ed8,color:#fff,stroke:#60a5fa,stroke-width:2px

Stage	What you do	Evidence for Validation Report
1 — Problem	Talk to real people who have your problem	Interview notes, Week 3 research
2 — Concept	Show an early sketch or mockup — do not explain it	Notes on what they did and said
3 — Usability	Give a real task. Stay quiet. Record what happens.	Session notes: who, what shown, what they did, what surprised you
4 — Iterate	Change something. Test again. Document before and after.	Before/after screenshots + “participant X couldn’t find Y, so we moved it to Z”

Where most teams are in Week 7: Stages 3 and 4. You should have run at least 2 sessions by now (Week 6 first sessions). You need 5+ documented sessions total for the Validation Report.

One session a week is much easier than five sessions in Week 9

If you have run one session so far, run two this week. If you have run zero, start today — a paper sketch is enough.

Template: ⬇ Validation Report — record today’s session in the notes section while it is fresh.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Mission 1 — Standup + sprint planning

Standing ritual — every session from Week 5 through Week 9. Three questions each, two minutes per person:

1. What did I do since the last session?
2. What will I do in this session?
3. Any blockers?

15:00

2 minper person 15 minstandup 25 minplanning

▶ Start ↺ Reset

After the standup — update your Kanban:

• Move completed tasks to Done
• Every developer has exactly one task in Doing with their name on it
• Sprint goal check: what did you say last week? Did you ship it?

Sprint planning question for Week 7: By the end of this session, what will a real user be able to do that they could not do last week? One sentence. Write it on the board.

Team discussion opener: What matters most before Demo Day — and is that what your team is working on right now? Building more is not always the answer. Write your answer next to the sprint goal.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Mission 2 — Validation — second round

By Week 7 you should be in Stage 3: Usability Testing. Run real sessions with people who are not on your team.

Quick session recipe (20 minutes):

1. Opening (2 min): “We are testing our product, not you. There are no wrong answers. Please think out loud as you go.”
2. Give a task (not a question): “Imagine you want to [user goal]. Show me what you would do.” — then stop talking.
3. Observe (15 min): Note what they try first, where they pause, what they say. Do not help them.
4. Debrief (3 min): “Was anything confusing? What did you expect to happen when [the thing that failed]?”
5. Write it up (10 min after): One paragraph. Who (role, not name), what you showed, what they did, one thing that surprised you.

What changes this week: You have run at least one session now. You know what broke. Fix one thing based on that finding — then test the fix in a second session this week.

This is the iteration loop

Finding → Change → Test again. That three-step cycle, repeated with documented evidence, is what the Validation Report assesses. One strong iteration loop is worth more than five sessions with no changes.

See the Validation Guide for the full session template and note-taking format.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Mission 3 — AI agents — working smarter

By now most teams have used AI tools to help build their product. Here is the pattern that gets better results — based on what has worked and not worked across many teams this semester.

Why vague prompts produce bad results

An AI agent builds what you describe. The less context you give, the more it guesses. When it guesses wrong, you get something generic that does not match your product.

Vague prompt:

“Build me a login page.”

Result: A generic form with no connection to your product, your users, or how you defined “done”. You spend an hour starting over.

Structured prompt (what actually works):

“I am building [one sentence about your product]. Stack: [frontend] + [database/backend]. Here is the user story I am implementing: [paste the user story]. Acceptance criteria: [paste the bullets — the things that must be true for this to count as finished]. Generate the [screen / feature / form] for this. Do not add features beyond these acceptance criteria.”

The difference: the AI now knows what to build, how to build it, and when to stop.

Where do “acceptance criteria” come from?

In Week 5 you wrote 2–4 bullets under each user story — things like “volunteer can see the last feeding in under 5 taps” or “a confirmation message appears within 2 seconds”. Those are your acceptance criteria. Paste them straight into the prompt. See the MiaoLog example →

Use your existing documents as input

You have already written the inputs the AI needs. Use them:

Document	What to paste as context
User story	The full story — “As a [role], I want [action], so that [outcome]“
Acceptance criteria	The 2–4 bullets under each user story — they define the finish line
Architecture	Your stack — prevents the AI from suggesting incompatible tools
Design description	Describe the screen layout in plain language: “There is a card at the top with the cat’s name and photo. Below it, a list of feeding entries. Each entry shows time, food type, and amount.”

Upload your design as an image

Many AI tools accept image uploads. If yours does, paste in a screenshot of your design or a photo of your hand-drawn sketch. Then ask: “Here is a design for [feature]. Build the screen that matches this layout.” The AI reads the image and builds what you drew.

Skip the copy-paste — use a spec folder

If you are using an AI coding agent (a tool that works inside your project, not just a chat window), you do not need to paste context into every prompt. Add these files to your project once — the agent reads them at the start of every session.

Worked example — all files, filled in

MiaoLog (喵Log) — the campus cat app from this course

A complete spec folder: product requirements, user roles, user stories with acceptance criteria, technology choices with rationale, and a full UI spec. Open it, read it, then model your own files on it.

View MiaoLog-WorkedExample on GitHub →

What goes in each file — with MiaoLog examples:

your-project/
├── product-requirements.md  ← what it is, problem, requirements, out of scope
├── user-roles.md            ← who the users are and what each role can do
├── user-stories.md          ← user stories + acceptance criteria
├── technology-choices.md    ← your confirmed tools and why you chose each one
├── ui-spec.md               ← colours, fonts, screen layouts (optional)
└── designs/                 ← screenshots or photos of your design (optional)
    └── home-screen.png

product-requirements.md — problem, requirements table, constraints, out of scope:

MiaoLog is a mobile web app for campus cat volunteers. Volunteers log feedings and health notes. Group coordinators monitor all cats. Core requirement R1: volunteer can log a feeding in under 30 seconds.

user-stories.md — copy from your PRD, one story per feature:

As a volunteer feeder, I want to record who fed which cat, when, and how much, so that other volunteers can check before feeding. Done: volunteer sees last 24h of feedings in under 5 taps · confirmation appears after logging · warning shows if same cat fed twice in 10 minutes

technology-choices.md — your confirmed tools and the reason for each:

Frontend: Vue 3 — team knows it. Database: Supabase — generates a full API from our database, the app reads and writes directly from the browser with no server code. No native app — mobile browser is enough.

Once the folder exists, start each AI session with:

“Read the files in this folder. Then help me build: [paste a user story from user-stories.md].”

The agent reads your product description, your stack, your acceptance criteria, and your design images — all at once. No copy-paste. Each new task starts with the same one-line prompt.

Chat tools vs. agent tools

A chat tool (browser-based) needs you to paste context manually each time. An agent tool (runs inside your project folder) can read your files directly. Both work — the spec folder saves time with agent tools, and you can still paste the file contents into a chat tool if that is what your team uses.

The AI agent loop — one task at a time

The teams that get the most from AI agents are not the ones who write the biggest prompts. They are the ones who break work into small tasks and test each result before moving on.

1. Pick ONE task from Kanban
2. Write the structured prompt (user story + acceptance criteria + stack)
3. Generate the output
4. Try it — does it do what the user story says?
5. If yes → save your progress.
   If no → paste the result back in and ask the AI to fix it.

Not sure what the AI built? Ask it.

Paste the output back into the chat and ask: “Walk me through what each part of this does.” or “How do I run this?” The AI can explain its own output — and in some tools it can run it for you directly. You do not need to understand every detail to make progress.

Common patterns that have caused problems

What teams did	What went wrong	Better approach
Asked AI to “build the whole app” in one prompt	Output was generic and did not match any user story	One user story at a time
Used AI output without testing it	Feature looked right but did not match what the user story required	Try it out before moving on
Gave no stack context	AI suggested tools not accessible from China	Always include your confirmed stack
Described the UI without acceptance criteria	AI added features nobody asked for	Paste your acceptance criteria as the stop signal
Used design tool name as a verb (“Figma this”)	AI generated design files, not a working feature	Describe the layout in plain language or upload the image

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

In case you are wondering where the theory is

Every practice in this module maps to a named framework — Scrum, Design Thinking, Lean Startup, BDD, and more. If you want the academic names to use in your Dev Log or Technical Documentation, see the Theory in Practice reference page.

---

Mission 4 — Build sprint

Sprint 3 is the last sprint with comfortable time before Demo Day. Use it.

If your team is blocked:

Blocker	What to do
Cannot agree on what to build	Look at your user stories — what is the smallest done condition not yet working?
AI output does not work	Paste the error back in, include your stack and exact error message
Feature is too large for one session	Split it — front end only, or data model only, or just the UI with no backend yet
Someone is not contributing	Name it in the standup, note it in the Dev Log, message your pathfinder

Commit standard:

feat: user can submit a new feeding entry
fix: feeding form no longer clears on validation error
docs: update architecture section with confirmed stack

Every commit that goes into your Dev Log should have a message a pathfinder can read in three seconds and understand what changed.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Before you leave

What today feeds into your grade

Architecture documentation → Technical Documentation (Week 11, 15%). Validation sessions → Validation Report (Week 11, 10%). Commits today → Technical Documentation + individual Dev Log entry. AI agent practice → every build session from here.

Five things to have done today:

/ completed — progress saved in your browser