Week 3

You have been saying “sprint” for two weeks. This week it gets a definition, along with the backlog, the user story, and what it means to call something finished. The second class puts the data and the cost underneath all of it.

Before the first class

• Do the first-class readings listed below. They carry the vocabulary the class uses from the first minute.
• Bring your team's problem statement. The class turns it into a backlog.
• Nothing new to install.

The first class

Two things: what a sprint is, and how five or six people build at the same time without colliding. Both come back as Phase 2, and you are asked about them individually.

Sprints, and what “done” means

A sprint is a fixed block of work. In this course it is two weeks, and it ends at a delivery session where you show what runs. Then the next one starts, immediately. The date does not move. Scope flexes.

The backlog is the ordered list of everything not yet built. Ordered, not just listed — the order is a decision, and the Client Lead owns it. A list is not a backlog. If nobody can say what is next, nothing has been decided.

A user story is one unit of work, described from the point of view of whoever benefits. It has to be small enough for one person to finish inside one sprint. If it is not, it is not a story yet — split it. It is not a task list and not a screen description. The shape is three lines:

As a shop owner
I want to see the orders that arrived today and are not yet recorded
So that nothing is lost before closing

Who benefits, what they want, why it matters. The third line is the one teams skip and the one that survives.

Acceptance criteria are written before the work starts, and they must be checkable by someone who did not do the work. If nobody else can check it, it is not acceptance criteria. They are not a description of the feature. They are the test that ends the argument about whether it is done.

Done has four conditions, and you need all four:

1. Built — it runs.
2. Reviewed by a teammate, who says what they checked.
3. Accepted by the Client Lead.
4. Visible working — not on your laptop.

Miss any one of the four and the story is not done. There is no partial done. What is not finished does not disappear either — it goes back to the backlog, and the Client Lead decides where.

From a problem to a backlog

Four steps, in that order:

1. Persona — who this is for.
2. Epic — a large chunk of value.
3. Story — one unit of work.
4. Acceptance criteria — how you know it is done.

Two personas per project is enough. Five is procrastination. A persona is who the system is for, not a biography: a name, what they are trying to do, and what gets in the way.

Building at the same time

Here is what goes wrong without an agreement.

With an agent on each side, both halves now appear in an afternoon — which makes the mismatch more likely, not less. Speed is no longer the constraint. Agreement is.

You already have the two places where that agreement is written down, and there is no third document to produce.

• The schema is the agreement. The table, its columns, and which of them may not be empty — that is what passes between you. customer_full_name is a column, not a preference. The Data Lead writes it, and it changes only in a pull request both of you have read.
• The acceptance criteria carry the rest. What the other half is handed, and what it does when something is missing, belongs in the story before anybody builds. An order with no customer shows as “unassigned”, it is not hidden.

The order you work in:

1. User story — what someone needs, in their words.
2. Acceptance criteria — how you will know it is done, including what happens when a value is missing.
3. Schema — the nouns in the stories become tables.
4. Screens and code — both consume everything above.

Schema before screens. Nobody starts at step 4. Ten minutes on the schema and the criteria, before either of you starts, saves a day — and it is the best prompt either of you can give an assistant, because it says exactly what to produce.

This is the whole reason the split works. Without an agreed shape the work serialises and one person becomes the bottleneck. Every student takes at least two named stories per sprint and builds each one end to end, and that only holds if the shape was agreed first.

• Slides — Sprints, and building at the same time

Before the second class

• Nothing new to install.
• Do the second-class readings below.

The second class

Two things: the data underneath the system, and what the agent's work actually costs. You should leave with your own schema drawn.

Tables, rows, columns, keys

A table is one kind of thing — orders, customers, products. A row is one of them. A column is one fact about it: the total, the date.

A primary key is how you name one row unambiguously. Never two rows with the same one. Usually just id. Without it you cannot say this order, only “an order that looks like this”.

A foreign key is how one table points at another. The order_items table holds an order_id. That is the entire mechanism — a column holding another table's key, nothing more clever.

One-to-many is the relationship that follows: an order has many items, an item belongs to one order. Two tables, and the arrow points one way. It is the only relationship most of your projects will need. Learn it properly rather than learning four badly.

Decide the schema before you fill in the screens. A screen is cheap to change. Data already in a table is not.

Who is allowed to read what

Your anon key sits in the page, where anyone can read it. That is normal and it is by design. It is safe only because of what comes next.

Row-level security decides who may read and write. Per table. Every table. With it off, anyone who opens your page can read everything, change it, and delete it — including your client's real data, from a browser, with no account.

Never real data. No real customer information in the repository, and none in a prompt, ever. Invent test data instead. The agent is very good at generating fifty realistic fake orders — ask it for those.

What the work costs

A token is roughly four characters of text. Everything the model reads is counted, and everything it writes is counted. You pay for the reading, not just the answer: the file you attached counts, and the folder you pointed at counts.

Cost follows the work, not the prompts. One long agentic run can cost far more than twenty short questions. What is consumed is how much the agent does, not how much you type. “I only sent three messages” explains nothing.

What you can see differs by tool:

• Antigravity shows your own remaining limits, refreshing on roughly a five-hour cycle.
• Gemini Enterprise shows an end user nothing at all — the usage dashboard is administrator-only. Nobody is withholding a number from you; for the browser tool there is no per-user number to read.

So plan where the work belongs. Planning and writing go in Gemini Enterprise, in the browser. Building goes in Antigravity, on your machine. Thinking done in the browser is thinking the IDE does not have to pay for.

Context is the lever. Cost scales with how much the model has to read. Two named files beats “look at the whole folder”. Say what done looks like before it starts, so it does not go exploring. The cheaper version is usually the better version, because a narrow question gets a narrow answer you can actually check.

When the quota runs out, in this order:

1. Narrow the ask — one file, one story, one question.
2. Move the thinking to the browser, and keep the machine for building.
3. Your own key — the personal fallback.
4. By hand, and wait for the refresh.

The last rung is not a failure. Part of this work is yours to do by hand, and a team that cannot do it is a team that stops.

You should leave this class with your own schema drawn.

• Slides — The data underneath it, and what the work costs

Due this week

Nothing is delivered in week 3. One thing still ends here: no team passes the end of this week without an accepted proposal. If yours is not accepted by then, the instructor assigns a project from a standing list and the proposal component scores zero. See deliverables for the dates and for what happens next.

Three things are due before the end of week 4, as part of Phase 2:

1. Draw the schema, with keys marked.
2. Turn row-level security on, on every table.
3. Write the token plan.

Your token plan must say five things:

• Where each kind of work happens — planned in the browser, built on the machine.
• Which model for which task, and why that one.
• The tactics your team will use to keep a run narrow.
• What you will watch, and what you have no way of seeing.
• What you do when the quota runs out — decided before it does.

Short and specific beats long and general. Phase 2 is worth 10 marks; the full checklist and the date are on deliverables.

Read

For the first class

The GOV.UK page is deliberately plain English. If it lands, the Atlassian one is a second angle rather than new material.

For the second class

On the tokens page, read the concept section and skip the code samples. The Antigravity page is the only first-party usage signal you can actually see.

Use

• Team roles — who owns the backlog, the schema, and the ledger.
• Your repository — where the schema, the stories and the plan live.
• Deliverables — the dates, the weights, and the Phase 2 checklist.