Guild Operations

The hook#

Last session you pinned the quests to the board and ranked them. The board is honest, every card knows where it came from, and nothing is in the Sprint 1 column, because moving a card there is a promise and a promise needs a size. Today you put a number on every Must and Should story, and you do it without guessing hours, by comparing each story with something you have already built. The guild hall's login took you one session in 4.9 and again in 4.15. That is a five. A list page that fetches one resource is a two. Everything else is measured against those.

Then the backlog becomes a plan with the shape Unit 12 actually has: four sprints, one per session from 12.1 to 12.4, each with the session's hours plus the hours you will really give it before the next one, each with a capacity in points and a visible line for slack. Sprint 1 gets a goal in one sentence and a Definition of Done you can check with your eyes. And because a retrospective is a skill you practise, not a form you fill, you run one in this session on the Unit 7 test suite you finished in 7.4 and pick one experiment to carry into Unit 12.

A guild that spends six months planning the perfect raid arrives to find the dungeon patched. A guild that raids for a week, counts the loot, and adjusts clears it in two months.

The idea#

Plan a little, build a little, look#

The old way treated software like a bridge: specify everything, build in sequence, test at the end, hope. Bridges do not change their minds halfway through. Software does, because users do, and because the first version teaches you things the specification could not know. The Agile Manifesto, written in 2001, is four preferences, and the things on the right still matter; when the two sides conflict, you lean left.

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Agile is not "no planning". It is just enough planning, just in time: plan the next sprint in detail and the rest in outline, build, show it to someone, learn, and plan again with what you learned. The retro at the end of every sprint is where the learning gets written down, which is why skipping it is how a team repeats the same week forever.

Scrum, sized for a party of one#

Scrum is the most common frame for working that way. It is a framework, not a method: it gives you the structure and you fill in the details. The 2020 Scrum Guide, which is short and free and the one reference this session leans on, defines three accountabilities, the Sprint plus four events inside it, and three artifacts, each with a commitment.

The Sprint is the container. A fixed length, scope does not change inside it, and a new Sprint starts the moment the last one ends. Inside it, four events:

• Sprint Planning at the start: pick stories from the backlog that serve one goal, within capacity. Output: the Sprint Backlog and a Sprint Goal in one sentence.
• Daily Scrum: fifteen minutes, every working day. What moved yesterday, what moves today, what is blocked. Solo, this is three lines in the plan file every day you work on the capstone.
• Sprint Review at the end: show the working increment to someone who cares. Working software, not slides. Solo, this is a two-minute screen recording of the real thing, which you watch back, and which you send to one interviewee if they offered to look.
• Sprint Retrospective after the review: what went well, what did not, what one thing changes next sprint. Solo, this is the template at the end of this page, filled honestly, with one experiment.

Three artifacts, three commitments: the Product Backlog commits to a Product Goal (your MVP sentence); the Sprint Backlog commits to a Sprint Goal; the Increment commits to a Definition of Done. Each artifact is a list, and each commitment is the sentence that says what the list is for.

On a large team these are three people and four meetings. On a capstone they are three hats and four habits, and the habits are the point. Pair programming is the fifth habit on real teams, driver and navigator swapping every twenty minutes; the solo version is explaining each chunk aloud to a rubber duck or to the AI chat from Unit 5, which exposes the gap between what you meant and what you wrote just as reliably.

Relative size, calibrated on the hall#

Developers are bad at hours, reliably off by a factor of two or three, and hours punish the honest estimator. People are good at comparing. Story points are relative sizes: a two is about twice a one, a five is bigger than a three by more than the numbers suggest, and the scale skips numbers on purpose so you cannot pretend to know the difference between a six and a seven.

T-shirt sizes are the beginner's scale and Fibonacci points are the one teams use; here is the one mapping this path uses, and the row that has no number is deliberate.

An 8 exists on the Fibonacci scale, and you may use it for an L that you know will spill; a 13 is a story that should already have been split; a 21 is a project. XL has no points at all. If you cannot estimate it, you do not understand it yet, and a story you do not understand does not enter a sprint. Split it until each piece has a number. The reminder text in the tutor ledger needs a text-message provider, a scheduler, and a consent flow, three things you have never built; it is XL, and it stays in Could until it is three stories or until Unit 10 changes what you know.

Planning poker is how a team estimates: everyone shows a card at once, and the disagreement between the two and the thirteen is the useful part, because it exposes a misunderstanding. Solo, you get the same effect by writing one sentence of reasoning next to every number, which is the rule for the sizes table in your file. If you cannot write the sentence, round up.

Velocity is the total of points finished in a sprint. After two sprints you know yours, and you use it to plan the third. It is a planning number, not a score, and the moment it becomes a target it stops measuring anything, because the only way to raise it is to inflate the estimates. Do not try to increase it. Try to predict it.

Four sprints before the final demo#

Unit 12 has four build sessions: 12.1 Foundation, 12.2 Build, 12.3 Harden, and 12.4 Polish, followed by a demo in 12.5. Work through them in order, on the days you choose. A sprint on this path is one of those sessions plus the hours you give it before the next session begins. That is the shape the plan takes today, and the plan the learner in you writes has to fit the sprints the builder in you will run.

The hours are yours to set, and setting them honestly is the whole exercise. Count the evenings you actually have between the sessions, not the ones you hope for. The capacity in points comes from the calibration: one session holds roughly the guild hall's login plus a list, a five and a two, so a session plus four evening hours holds something like ten to twelve points. Write the number, then plan under it, and leave the difference in the table as a row called slack. The slack is for the thing you did not predict, and there is always one.

Every Must story lands in Sprint 1 or Sprint 2. Sprint 3 is tests, security, and deploy, which Units 7, 10, and 6 taught and which take a full session whether or not you believe it. Sprint 4 is where Should stories go, if the first three left room, and where the demo gets its seed data and its script.

The Sprint 1 goal and the Definition of Done#

A sprint is not a calendar box with unrelated tickets in it. The goal is one sentence that names a capability a person will have at the end, and it is what you use to say no to a card halfway through. "A tutor can sign in, add a client, log a lesson, and see it in the unpaid list" is a goal. "Do stories 1, 2, 3" is a list. If capacity shrinks, you cut scope and keep the goal; the goal is what you renegotiate against.

The Definition of Done is the Increment's commitment, and it is a list of evidence, not a feeling. For the capstone, a card is Done when the acceptance examples pass by hand, the code is committed on a branch and merged to main, there is a Supertest or Playwright case for the path from Sprint 3 onward, the browser console is clean, and the card is in Done with a one-line note. Acceptance is not release: an increment can be Done and not yet deployed, and a deploy does not excuse a missing test.

The board shows flow, the retro changes the next sprint#

Four columns: Backlog, Sprint 1, In Progress, Done. Only one or two cards live in In Progress at a time, because three half-finished stories are zero finished stories. A blocked card gets a reason and a next action written on it, not a red label. During a sprint, the daily three lines are about the board: which card moved, which one is stuck, what you do about it today.

A retrospective is three questions and one experiment. What went well, and keep doing it. What did not, and stop. What one thing changes next sprint, as a specific action with an owner, which is you. One experiment small enough to try before the next retro beats ten observations. At the next retro, check that one thing first.

The napkin version: size by comparing, not by clock. XL has no number. Four sprints, one per Unit 12 session, each with hours, capacity, and slack. A goal is a sentence about a person, not a list of cards. Done is evidence. One or two cards in progress. One experiment per retro.

The demonstration#

The tutor ledger's backlog from last session, sized and shaped. The file is docs/sprint-plan.md. Copy the template into yours and fill it in; the filled example follows.

# Sprint plan: <capstone-name> ## ShapeFour sprints, one per Unit 12 session, plus the hours between sessions. | sprint | session | hours (session + between) | capacity | goal ||---|---|---|---|---|| 1 | 12.1 Foundation | | | || 2 | 12.2 Build | | | || 3 | 12.3 Harden | | | || 4 | 12.4 Polish | | | | ## Sizes| # | story | size | points | why ||---|---|---|---|---| ## Sprint 1Goal: <one sentence about what a person can do at the end> | # | story | points ||---|---|---|| | total | || | capacity | || | slack | | ## Sprints 2–4 (directional)- Sprint 2:- Sprint 3:- Sprint 4: ## Definition of Done- [ ] acceptance examples pass by hand- [ ] committed on a branch and merged to main- [ ] a Supertest or Playwright case for the path (from Sprint 3)- [ ] no console errors- [ ] card in Done with a one-line note ## Ceremonies, solo- planning: first 30 minutes of each Unit 12 session, in this file- daily: three lines under Daily log, every day I work on it- review: a two-minute screen recording at the end of each sprint- retro: the template below, one experiment ## Daily log### <date>- moved:- today:- blocked: ## Retro: <sprint or project>### Went well### Did not go well### One experiment- action:- owner: me- check at the next retro:

The sizes table, with the sentence that justifies every number. The story numbers are from docs/user-stories.md.

## Sizes| # | story | size | points | why ||---|---|---|---|---|| 1 | Sign up and log in | L | 5 | Did it in 4.9 and 4.15; still the most lines, two routes, a hash, a token, and a guard. || — | Client and Lesson models with a seed | S | 2 | Two models, one ref, a seed script; written four times in Unit 4. || 3 | Log a lesson | M | 3 | A form with a client select, a date, a fee, validation, and an error state. || 4 | Unpaid list | S | 2 | One query with paid = false and owner = me, sorted; a table and an empty state. || 5 | Mark paid | S | 2 | An owner-scoped PATCH and a button; the 404 for other owners is the only edge. || 2 | Add a client | XS | 1 | A name and a rate; it is the first screen of story 3. || 6 | Client page | M | 3 | A detail page with two lists and a total; new query shape. || 9 | Edit or delete a lesson | M | 3 | Two more owner-scoped routes and an edit form. || 8 | Monthly total | S | 2 | One aggregate over lessons I already have. || 7 | Statement link | L | 5 | A public route with a token I have not built before; a page with no login. || 10 | CSV export | S | 2 | One route that writes rows; no new model. || 11 | Reminder text | XL | — | Needs a text provider, a scheduler, and consent. Three unknowns. Split or leave in Could. |

Read the reasons. Login is a five not because it is hard but because it is the most lines and has the most places to go wrong, and you have the two earlier versions to measure against. The unpaid list is a two because it is a single query and a table you have built in every Unit 4 project. The statement link is a five because it is the one Should story with a shape you have never built. The reminder text has no number and the reason says why.

The sprint table with the hours filled for a learner who has two evenings between 12.1 and 12.2 and three between 12.2 and 12.3.

## Shape| sprint | session | hours (session + between) | capacity | goal ||---|---|---|---|---|| 1 | 12.1 Foundation | 3 + 4 | 12 | A tutor can sign in, add a client, log a lesson, and see it listed. || 2 | 12.2 Build | 3 + 6 | 13 | A tutor can see who owes what, mark it paid, and fix a mistake. || 3 | 12.3 Harden | 3 + 6 | 13 | The Must paths are tested, locked down, and live on Railway. || 4 | 12.4 Polish | 3 + 3 | 8 | A client can be sent a statement link; the demo has real-looking data. |

Sprint 1, selected within capacity, with the slack written down.

## Sprint 1Goal: A tutor can sign in, add a client, log a lesson, and see it listed. | # | story | points ||---|---|---|| 1 | Sign up and log in | 5 || — | Client and Lesson models with a seed | 2 || 2 | Add a client | 1 || 3 | Log a lesson (and see it in a plain list) | 3 || | total | 11 || | capacity | 12 || | slack | 1 | ## Sprints 2–4 (directional)- Sprint 2: #4 unpaid list (2), #5 mark paid (2), #6 client page (3), #9 edit/delete (3), #8 monthly total (2). Total 12 of 13.- Sprint 3: Supertest for the Must routes (5), Unit 10 security pass (3), Railway deploy with a domain (3). Total 11 of 13.- Sprint 4: #7 statement link (5), demo seed and README (2). Total 7 of 8.

Every Must is in Sprint 1 or 2. The two Could stories are not in any sprint, and the file says where they wait. If Sprint 1's slack turns out to be negative on the day, the goal says what to cut: the plain list in story 3 can wait for Sprint 2's unpaid list, and the goal still holds for sign in, add a client, log a lesson.

Now the board. Open the project from last session. Add a number field called Points: in the project's settings, Fields, New field, type Number, name Points; or from the terminal:

gh project field-create 1 --owner "@me" --name Points --data-type NUMBER

Created field

On the Board view, type each card's points into the field, and drag the four Sprint 1 cards from Backlog into Sprint 1. Everything else stays in Backlog. The In Progress column is still empty, and it stays empty until 12.1, because a card in progress is a promise to today.

The retrospective. You have not run a capstone sprint yet, so the practice retro is on the Unit 7 test suite, which you finished in session 7.4. Here is the example filled; yours will have different rows.

## Retro: Unit 7 test suiteSession: 8.3 — retrospective on the Unit 7 suite ### Went well1. Jest ran on the first try; no config fight.2. Writing the Supertest cases found a real bug in the inbox route's 404.3. Finished in 7.4, before beginning the research in 8.1. ### Did not go well1. Three hours on one Playwright test that flaked on the login redirect.2. Read the Playwright docs after getting stuck, not before.3. One huge commit at the end instead of one per passing test. ### One experiment- action: when stuck for thirty minutes, write the question down in full and  put it to the AI chat before trying a fourth time; set a timer.- owner: me- check at the next retro: did the timer go off, and what happened next?

One experiment, not three. "Commit after every passing test" and "read the docs first" are real lessons, and they go in Went well and Did not go well as observations; the experiment is the one you will actually check in Sprint 1's retro.

Here is a small model you can run here. It proves that the size mapping gives an XL no number, that each of the four sprints fits its capacity with slack visible, that every Must story lands in Sprint 1 or 2, and that adding one more story to Sprint 1 is refused by the plan before the sprint starts. It does not prove your hours are honest or your fives are fives; the calibration against the hall is something only you can do.

function check(condition, message) {  if (!condition) throw new Error(message);  console.log('PASS:', message);} const SHIRT = { XS: 1, S: 2, M: 3, L: 5, XL: null };function points(size) {  if (!(size in SHIRT)) throw new Error('unknown size ' + size);  return SHIRT[size];}check(points('L') === 5 && points('S') === 2, 'login is a five because a list is a two');check(points('XL') === null, 'an XL has no number: split it before it enters a sprint'); const sprints = [  { n: 1, session: '12.1', capacity: 12 },  { n: 2, session: '12.2', capacity: 13 },  { n: 3, session: '12.3', capacity: 13 },  { n: 4, session: '12.4', capacity: 8 }];const backlog = [  { id: 'login', size: 'L', moscow: 'Must', sprint: 1 },  { id: 'models-seed', size: 'S', moscow: 'Must', sprint: 1 },  { id: 'add-client', size: 'XS', moscow: 'Must', sprint: 1 },  { id: 'log-lesson', size: 'M', moscow: 'Must', sprint: 1 },  { id: 'unpaid-list', size: 'S', moscow: 'Must', sprint: 2 },  { id: 'mark-paid', size: 'S', moscow: 'Must', sprint: 2 },  { id: 'client-page', size: 'M', moscow: 'Should', sprint: 2 },  { id: 'edit-delete', size: 'M', moscow: 'Should', sprint: 2 },  { id: 'monthly-total', size: 'S', moscow: 'Should', sprint: 2 },  { id: 'tests', size: 'L', moscow: 'Must', sprint: 3 },  { id: 'security-pass', size: 'M', moscow: 'Must', sprint: 3 },  { id: 'deploy', size: 'M', moscow: 'Must', sprint: 3 },  { id: 'statement-link', size: 'L', moscow: 'Should', sprint: 4 },  { id: 'demo-seed', size: 'S', moscow: 'Should', sprint: 4 },  { id: 'reminder-text', size: 'XL', moscow: 'Could', sprint: null }]; function plan(sprint, items) {  const chosen = items.filter(function (s) { return s.sprint === sprint.n; });  const total = chosen.reduce(function (sum, s) { return sum + points(s.size); }, 0);  return { n: sprint.n, total: total, capacity: sprint.capacity, slack: sprint.capacity - total, fits: total <= sprint.capacity };} const plans = sprints.map(function (sp) { return plan(sp, backlog); });check(plans.length === 4, 'four sprints, one per Unit 12 session');check(plans.every(function (p) { return p.fits; }), 'every sprint fits its capacity');check(plans.every(function (p) { return p.slack >= 1; }), 'unallocated capacity remains visible in every sprint');check(plans[0].total === 11 && plans[0].slack === 1, 'Sprint 1 plans 11 of 12'); const musts = backlog.filter(function (s) { return s.moscow === 'Must' && s.size !== 'XL'; });check(musts.every(function (s) { return s.sprint === 1 || s.sprint === 2 || s.sprint === 3; }), 'every Must lands in a sprint before Polish');check(backlog.find(function (s) { return s.id === 'reminder-text'; }).sprint === null, 'the XL is in no sprint'); const overCommitted = plan(sprints[0], backlog.concat([{ id: 'client-page-too', size: 'M', moscow: 'Should', sprint: 1 }]));check(overCommitted.fits === false && overCommitted.total === 14, 'one more card in Sprint 1 is refused before the sprint starts'); console.log('ok: checkpoint-8-3');

Where it breaks#

Your turn#

The quest#

One deliverable: docs/sprint-plan.md in the capstone repo, pushed, with the board's Sprint 1 column matching its Sprint 1 table. It is complete when someone reading only that file could tell you what you will build on the first day of Unit 12, why those stories, and how you will know each one is done.

Evidence:

• A Sizes table with points and a reasoning sentence on every Must and Should story, and — on any XL with a note on how it splits.
• A Shape table with real hours, a capacity, and a goal sentence for each of the four sprints.
• A Sprint 1 table whose total is at or under capacity, with the slack row filled, and a Sprints 2–4 block that places every Must before Polish.
• A Definition of Done with at least five checkable lines, and the solo ceremonies with times.
• A screenshot of the board named board-sprint-1.png in docs/, showing Points on the cards and the Sprint 1 column matching the table.
• A Unit 7 retro with one experiment and a line saying how you will check it.
• The commit Sprint plan: sizes, four sprints, Sprint 1 goal, DoD, Unit 7 retro on GitHub.

Side quests#

Grit's training circle is plan, inspect, adapt told as a story, and the Open/Closed and Dependency Inversion rules on the SOLID page are what make a story Independent on the board: if finishing card four means reopening card two, that page names the coupling you have to cut before you estimate.

Before next session#

Finish the interviews. By 8.4 the log in docs/research.md needs P1, P2, and P3 written up, each within a day of its call; if one is still unbooked, message two more names tonight, because next session synthesises whatever is in the log and the spec is honest about how many that is. Nothing is running on your machine, and the board stays as you left it: Sprint 1 filled, In Progress empty. Next session starts with all three interviews open side by side, turns them into a combined empathy map and a set of insights, revises the backlog with a change log that names which row each change came from, and writes the product spec that Unit 12 opens on its first morning.