Sprints

From Friday, October 23, Foundry work runs in two-week sprints. Every student runs every sprint, whether you are staffed on a client engagement or not. Each sprint you choose your work from the sprint menu, say what you will do, do it, show it working, and say what happened.

The sprint replaces the weekly update email. Your sprint plan, review, and Loom demo are how Professor Murff, your teammates, and the Foundry know what you are working on.

The fall sprints

Sprint	Starts	Plan due	Wrap-up due
1	Fri, Oct 23	Mon, Oct 26, 11:59 PM	Fri, Nov 6, 8:00 AM
2	Fri, Nov 6	Mon, Nov 9, 11:59 PM	Fri, Nov 20, 8:00 AM
3	Fri, Nov 20	Mon, Nov 23, 11:59 PM	Fri, Dec 4, 8:00 AM

A sprint starts and ends at the Friday studio. The Wrap-up is due at 8:00 AM, when studio starts, so studio that day can open with demos.

Each sprint is worth 120 points across two Canvas assignments, Sprint N Plan (10) and Sprint N Wrap-up (110). See Grading in the syllabus.

The sprint menu

Each sprint, your plan holds one or two items from the menu.

Item	What it is
Build	Real work on any part of the value chain: discovery, design, engineering, go-to-market, pricing, sales and outreach, analytics, operations
Learn	A Claude course or chapters of the Product Management book, ending in proof you can use what you learned

Two items can share a sprint. For example: Build for your client, on go-to-market, plus Learn, Claude Code in Action, with a Skill your team uses on the client repo.

Who your Build is for

Every Build item names who the work is for.

Who it’s for	What that means
A client	Your part of an engagement the Foundry is staffed on, funded or unfunded
The Foundry	Work on the Foundry itself: internal tools, business development with a prospective client, a customer story, recruiting
Your own product	A studio project or a product you or your team own

If you are staffed on an engagement, your Build is for your client first. You can add a second item, such as a Claude course. If you are not staffed, choose freely.

Every Build plan names at least one person, other than you and Professor Murff, who will use or see the work: the client, a user, or a teammate who depends on it.

When your staffing changes mid-sprint, run /sprint-plan again. It records what changed and why, and your work is read against the plan as it stands at the end. Being staffed, unstaffed, or moved partway through a sprint costs nothing.

On a team, everyone plans, reviews, and demos on their own. Teammates often share a goal. Your plan says which part of it is yours, and your Output is graded on that part, with the team’s result as context.

What counts as Build output

The same rule applies whoever the work is for. Output is real, finished for this sprint, and checkable by the course. It does not have to be public, launched, or used by anyone yet.

If your work was	Output means
A feature or deployed change	It works, in a repo or deployed, and your demo shows it working
An agent, automation, or integration	It runs, and your demo shows it running
Design	The interface or the designs exist
Discovery or research	The findings are written up, with what you concluded
A client deliverable (memo, deck, plan)	The deliverable, and the decision it asks the client to make
A landing page or campaign	The page or campaign is built, published or ready to publish
Pricing or financial modeling	The model exists and runs on real numbers
Marketing or sales copy	The copy is finished
Selling, outreach, or business development	The asks are made and on record: who you asked, when, what you asked for, and what they said
Analytics or measurement	The tracking returns real data

If your work fits none of these, say in your plan what output means for it.

What counts as Learn output

Studying alone leaves nothing to check, so every Learn item ends in proof.

Learn from	Proof
A Claude course on the Anthropic Academy (see The Certification Track)	The certificate of completion, plus the thing the course teaches you to build, used in your real work: a Skill or custom command with hooks, an MCP server, an evaluation harness
Chapters of the Product Management book	Your /learn logs for those chapters, plus your result on the Builder practice exam

A sprint can be Learn only. A single course takes hours and a sprint is two weeks of work, so a Learn-only sprint covers two weeks of learning, for example several courses, or several chapters and the practice exam, each with its proof.

What you turn in

Deliverable	What it is	Where it is saved	How you turn it in	When	Points
Plan	Your menu items, who the work is for, your part, why, how you will know it is done, and how hard you expect it to be. /sprint-plan writes it with you	sprints/sprint-N-plan.md in your Foundry repo	Commit it, and paste its GitHub link into Sprint N Plan on Canvas	The Monday after the sprint starts, 11:59 PM	10
Output	What you finished this sprint, as defined above	The client repo, your own repo, a link, or your demo	Nothing separate. List every repo, app, and file under Work files and links in your README	Wrap-up due date	60
Review	What /sprint-review produces: a report on your sprint, then your answers to its retro questions	sprints/sprint-N-review.md in your Foundry repo	Commit it, and paste its GitHub link into Sprint N Wrap-up on Canvas	Wrap-up due date	25
Demo	2 to 3 minutes on Loom showing your work running	Loom	Paste the Loom link into Sprint N Wrap-up on Canvas	Wrap-up due date	25

Your Foundry repo

Your plans and reviews are saved in your own repo, made from the builder template, the same template MSB 341 uses. Name it <your NetID>_foundry, keep it private, and add Professor Murff (sdmurff) as a collaborator. If you also take MSB 341, keep the two repos separate: each course numbers its sprints differently.

Client code does not go in this repo. It stays in the engagement’s repo in the ai-foundry-byu organization, which Professor Murff can already see. Your Foundry repo holds your plans, your reviews, and a README listing your work files and links.

The first time you run /sprint-plan in the repo, it asks which course the repo is for. Answer AI Foundry. We set this up together in studio on October 23.

The plan

Run /sprint-plan on the first day of the sprint. It interviews you and writes sprints/sprint-N-plan.md:

# Sprint N Plan

**Menu:** Build, Learn, or both. For each Build, who it's for: a client
(name it), the Foundry, or your own product. For each Learn, the course
or chapters.

**Teammates:** Who else is working on it, or "Solo."

**Goal:** What will be true in two weeks that is not true now?

**My part:** Which part of the goal is yours.

**Who will see it:** The client, user, or teammate who will use or see the work,
and what they will see.

**Why this:** Why is this the right next thing?

**What done looks like:** How will you know the goal was met? Specific enough that
someone else could check.

**Predicted difficulty:** 1 to 5.

On time, with every field filled in, earns all 10 points. The plan is graded for completion, and your predicted difficulty is not graded. Aim high.

You can change the plan. Plans change once you learn something, and on client work they change when the client does. Run /sprint-plan again during the sprint. It asks what is changing and why, updates the plan, adds a dated note, and commits it. There is nothing to resubmit on Canvas: your plan link always shows the current file. A change with no note is the one thing to avoid, because nobody reading the plan can then tell what you set out to do.

The review

On or before the Wrap-up due date, run /sprint-review in your Foundry repo. It shows you the projects you worked in during the sprint and asks which ones belong to this sprint, including the client repo. It reads only the projects you confirm, then writes a report: when you worked, where you got stuck and how you got unstuck, what took the most time, and which Builder axes your work advanced. Nothing leaves your computer except the report.

Then it asks six retro questions:

1. Did you hit the goal? Yes, partly, or no, and why.
2. What did the client or your users say or do about the work? For a Learn-only sprint, who did you show it to, and what did they say?
3. What did the report show you that you did not expect?
4. If the plan changed, why?
5. Actual difficulty, 1 to 5, and why it differed from what you predicted.
6. What will you change next sprint?

Answer in your own words. It saves your answers exactly as you write them at the bottom of sprints/sprint-N-review.md, then commits and pushes the file.

If you know Scrum: your demo is the sprint review, and the retro is the retrospective. The review file holds the evidence for both.

The demo

Record 2 to 3 minutes on Loom showing your work running, with real content. No intro and no reflection: the work itself, opened, for most of the video. On a team, show your part and say what you did. For Learn, show the thing you built with it running, or explain one concept from what you learned using your own work.

If your work was	Your demo shows
A feature or deployed change	The feature in use: click through it
An agent, automation, or integration	It running, start to finish, on a real input
An evaluation harness or tests	The tests running and the results they return
Discovery or research	One or two of your notes opened, and what you concluded
A client deliverable	The deliverable, and the decision it asks the client to make
Design	The interface or designs, clicked or scrolled through
Go-to-market, pricing, or sales	The page, the model with one input changed, or the asks you sent and your pipeline

Loom only. A demo on Google Drive, YouTube, or an uploaded file scores 0. Set the Loom to “Anyone with the link” or share it with scott.murff@byu.edu. A video Professor Murff cannot open is not graded until it is shared.

Client confidentiality. Loom is an outside service. If your engagement’s confidentiality terms do not allow recording the client’s data, demo the same work on sample or fake data, and say so at the start of the video. If you are not sure what your client allows, ask Professor Murff before you record.

Keep real names, emails, and phone numbers off the screen.

The Wrap-up

Submit two links in Sprint N Wrap-up on Canvas: your review file on GitHub and your Loom. Before you do, make sure the Work files and links section of your README lists every repo, deployed app, certificate, and document someone needs to check your output.

Grading rubric

Category	Points	What earns full marks
Plan	10	Its GitHub link submitted on Canvas by the Monday deadline, with every field filled in. Graded for completion
Output	60	Your part of the plan, real, finished, and checkable, as defined for Build and Learn above. Read against your plan as it stands at the end, and, from Sprint 2 on, weighed by how hard the work was for you
Review	25	Report committed, with your retro answering all six questions and responding to something specific in the report
Demo	25	2 to 3 minutes on Loom showing your work running, with real or clearly labeled sample content, viewable by Professor Murff

Waiting on a client. A client engagement does not always produce something new every two weeks: a client goes quiet, a data export is late, a decision waits on their meeting. Output is read against what was in your control. Record what you were waiting on, when you asked, and what you did meanwhile, and that work is graded as output.

Goals that need someone else to say yes. A client sign-off, a prospect agreeing to a call, a user agreeing to test: you make the asks, and the other person decides the answer. For these goals, Output is graded on the asks you made and can show: who you asked, when, what you asked for, and what they said. A no or a “not yet” costs no points when the ask is on record and your retro says what you learned.

Demo length. A demo up to 3:30 loses no points. From Sprint 2, each started 30 seconds past 3:30 costs 1 point (3:31 to 4:00 is minus 1, 4:01 to 4:30 minus 2, and so on).

Late work. Canvas applies the late penalty: 10% per day, up to 9 days. Graders never deduct for lateness themselves.

Your sprint feedback

After each sprint is graded, your score appears in Canvas, and your sprint report appears on the Builder tab of your profile in the Foundry app, aifoundry.byu.edu/app. The report shows how each category was scored, what your work showed on the Builder axes, and what to do next sprint.

Questions about your sprint feedback: reply to the Canvas comment your score came with, saying which part of the report you mean and what you think was missed. Professor Murff reads every reply.