Who does what, and one story from start to finish

ISOM 472 — Fall 2026/2027

Dr. Mohammad AlMarzouq Week 4

ISOM 472: Project in IS — Kuwait University

Three parts today

Roles in practice

What each role produces, who it goes to, and what it never does alone.

One story, live

From issue to merge, in the example repository, step by step.

Phase 2

What good looks like, the checklist, how it is read. Then Quiz 3.

ISOM 472: Project in IS — Kuwait University

Roles in practice

Three questions for every role

ISOM 472: Project in IS — Kuwait University

Every role answers three questions

What do I produce?

Every sprint, not once.

Who do I hand it to?

A role that hands nothing on is not working.

What do I never do alone?

The line that protects the team.

Owning an area does not mean doing all the work in it. It means being the person I ask when it is wrong.

ISOM 472: Project in IS — Kuwait University

Client Lead

Produces

Stories as issues, each with acceptance criteria. Talks to the client.

Hands to

The member building each story — and the whole team, as the backlog.

Never alone

Accepts a story they built themselves.

The only person who accepts a story as done — and is expected to reject some.

ISOM 472: Project in IS — Kuwait University

Design Lead

Produces

The HTML prototype and the screen list. Keeps the interface consistent.

Hands to

Every builder — the screen, and the pattern they follow.

Never alone

Changes the shared pattern without the team reading it in a pull request.

ISOM 472: Project in IS — Kuwait University

Data Lead

Produces

The schema and seed data in Supabase. Row Level Security on every table.

Hands to

Every builder. The schema is the agreement between two halves.

Never alone

Changes a column. Only in a pull request both halves read.

ISOM 472: Project in IS — Kuwait University

Build Lead

Produces

The system running at its public address, plus release notes each sprint.

Hands to

The Client Lead and the Quality Lead — something running to check.

Never alone

Merges their own work. No exception for the Build Lead.

ISOM 472: Project in IS — Kuwait University

Quality Lead

Produces

Bug issues, each with steps to reproduce, tracked to a disposition.

Hands to

The member who built the story, through the issue.

Never alone

Closes a bug as "not a defect" without its builder seeing it.

A disposition is one of three: fixed, deferred, or not a defect. An open list nobody closes is not quality work.

ISOM 472: Project in IS — Kuwait University

FinOps Lead

Produces

The Sprint FinOps Ledger entry: what the AI work cost, and what changed.

Hands to

The team — and the Phase Lead, for the delivery.

Never alone

Lets an agent write the ledger. It records what the team observed.

From Phase 2 onward, 1 of each phase's group points is the ledger.

ISOM 472: Project in IS — Kuwait University

Phase Lead — on top of a standing role

Produces

The phase delivery note, written during the phase. Then the tag.

Hands to

Me. The Phase Lead is my point of contact for the phase.

Never alone

Does the phase's work themselves. Leading is keeping the board current.

The tag — phase-2 — is created after the last pull request of the phase is merged. The tag is what gets graded.

ISOM 472: Project in IS — Kuwait University

The handoff chain

story (Client)  ──▶  screen (Design)  ──▶  table + access rule (Data)

  ──▶  built and deployed (Build)  ──▶  bug issues (Quality)

  ──▶  cost logged (FinOps)  ──▶  accepted (Client)

Every arrow is something written in the repository. If it is only said aloud, the chain is broken.

ISOM 472: Project in IS — Kuwait University

Patterns that go wrong

  • Two members holding the same role while another role is empty
  • One member reviewing and merging every pull request
  • Roles that do not match the team size
  • Filling in a teammate's row, or signing for them
ISOM 472: Project in IS — Kuwait University

Whoever approves it, merges it.

Anyone on the team can be the reviewer. Never the author.

ISOM 472: Project in IS — Kuwait University

One story, start to finish

Issue → branch → commits → pull request → review → acceptance → merge

ISOM 472: Project in IS — Kuwait University

1 — The Client Lead opens the story

  • Issues → New issue → User story
  • Three lines: As a … I want … So that …
  • Acceptance criteria a teammate can check by doing them
  • The issue number is the story number. Issue #14 is story 14.
ISOM 472: Project in IS — Kuwait University

2 — A branch named after it

  • One branch per story
  • Named with the issue number first: 14-sign-up-form
  • Made from an up-to-date main

In Antigravity, check the branch name at the bottom of the window before you start typing.

ISOM 472: Project in IS — Kuwait University

3 — Commits: small, and your own

  • Commit from your own GitHub account
  • Small commits, as you go — not one at the end
  • The story number at the end of the message:

feat(signup): add sign-up form [#14]

A grey icon instead of your photo means GitHub cannot tell the commit is yours. It does not count.

ISOM 472: Project in IS — Kuwait University

4 — The pull request

  • Title says what changes: "Add the sign-up form"
  • Body: Closes #14
  • The AI-Assisted line — tool / what it produced / what you changed
  • AI-Assisted: none is equally fine. Leaving it out is penalised.
ISOM 472: Project in IS — Kuwait University

5 — A teammate reviews it

  • Files changed → Review changes
  • Write what you ran, what you read, what you clicked
  • Then choose Approve
  • Nobody approves their own — on your own pull request, Approve is greyed out
ISOM 472: Project in IS — Kuwait University

6 — The Client Lead accepts

  • Opens the story's acceptance criteria
  • Checks each one, with the page running
  • Accepts — or sends it back with the criterion that failed

A story is not done because the person who built it says so.

ISOM 472: Project in IS — Kuwait University

7 — Merge, and watch it close

  • The reviewer who approved clicks Merge pull request — never the author
  • Issue #14 closes by itself, because of Closes #14
  • The story moves to Done on the board
  • Delete the branch — the history keeps it
ISOM 472: Project in IS — Kuwait University

Mistakes we have already seen

Mistake Instead
Pull request titled with one letter A title that says what changes
Closing a pull request instead of merging it Closed never reaches main. Merge pull request
Closes 14 Closes #14 — without # nothing closes
A branch left behind main for days Update it from main before review
Merging before the Client Lead has seen it The Client Lead accepts first
Approving in ten seconds with no comment Say what you ran, read and clicked

Update from main before asking for review. Conflicts: a short clinic opens the delivery session.

ISOM 472: Project in IS — Kuwait University

Phase 2 — what you deliver

What good looks like, and the checklist

ISOM 472: Project in IS — Kuwait University

The delivery note — the one page I read first

What it is

docs/delivery-notes/phase-2.md. Written by the Phase Lead during the phase. Half a page to a page.

What it does

Tells a reader where everything is and who did it. At the tag, it is the map of your repository.

What it is not

A list of commits. An essay. Something written on the last night by whoever is free.

At the delivery you present from it. The headings of the note are the order of your talk.

ISOM 472: Project in IS — Kuwait University

Five headings, in this order

Heading What goes under it — Phase 2
1. What was decided The design, in plain language: who the users are, the handful of things they can do, the tables that hold it. Five to eight lines.
2. Who did what One line per member: name, the stories they wrote and the ones they are assigned to build. Everybody appears.
3. Where everything is A link for each deliverable: personas, backlog copy, db/schema.sql, docs/schema.md, prototype, ledger section, the issues.
4. The tag phase-2 — lowercase — created after the last merge.
5. Not finished, and where it went What was planned and is not there. Moved to Phase 3, dropped, or replaced. Say which.
ISOM 472: Project in IS — Kuwait University

What a good one looks like — 1 of 2

Basket Register — Phase 2 delivery note (a fictional team of five)

1. What was decided. Volunteers at the Jahra branch register families, record a monthly basket collection, and are stopped from recording a second collection for the same family in the same month. Two personas: the counter volunteer and the branch coordinator. Four tables: families, collections, volunteers, areas. RLS: volunteers read and insert; only the coordinator updates or deletes.

2. Who did what.

Name Wrote Assigned to build (Phase 3)
Dana (Client Lead, Phase 2 Lead) #12 #13 #14 #19 #20 #21 #22 #23 #12 #13
Lulwa (Design Lead) #15 #16 #17 #18 #15 #16
Shaikha (Data Lead) #24 #25 #26 #27 #28 #24 #25
Noura (Build Lead) #29 #30 #31 #32 #33 #29 #30
Ghalia (Quality and FinOps Lead) #34 #35 #36 #37 #38 #39 #40 #41 #34 #35
ISOM 472: Project in IS — Kuwait University

What a good one looks like — 2 of 2

3. Where everything is. Personas — docs/personas.md. Stories — the Issues tab, label story, 30 open; copy at the tag in docs/backlog.md. Schema — db/schema.sql (four tables, keys, RLS policies; runs on an empty project) and docs/schema.md (what each table means, how they relate, who may read and write). Prototype — prototype/ (six screens, index in prototype/README.md). Token plan and first entry — docs/finops-ledger.md, "The plan" and "Phase 2".

4. The tag. phase-2, created by Dana after pull request #44 merged.

5. Not finished, and where it went. The floor for five is 40; we have 30 stories with criteria. Ten more are opened as #42–#51 without criteria and are the Client Lead's first job in Phase 3. The "export to spreadsheet" story (#38) moved to Phase 5 because it depends on the monthly count. The proposal's SMS reminder is dropped — the branch has no sender; recorded in proposal §6.

Short. Every line is a place or a name. Nothing in it needs me to ask a question to find.

ISOM 472: Project in IS — Kuwait University

Phase 2 — everything, where it lives, who owns it

Deliverable Where Owner Done means
Personas docs/personas.md Client Lead 2–4 named roles, a paragraph each; example persona deleted
Stories with criteria Issues, label story Client Lead at or above the floor; every criterion checkable; none outside proposal §6
The split Assignee on every story Client Lead every member assigned ≥ 2; nobody holds all
Boundaries criteria on stories that share data both builders name the schema columns that pass, and what happens when one is missing
Schema — the SQL db/schema.sql Data Lead runs on an empty project; keys, RLS on, a policy — every table
Schema — the document docs/schema.md Data Lead what a row means, how tables relate, who reads/writes and why; no column lists
Backlog copy docs/backlog.md → "Phase 2" Client Lead the open stories at the tag, with who
Token plan + first entry docs/finops-ledger.md FinOps Lead five lines answered; ≥ 1 row per member who used an assistant
Environment — Build Lead every member has one own-account commit this phase
Delivery note docs/delivery-notes/phase-2.md Phase Lead five headings filled; links resolve
Tag phase-2 Phase Lead exactly phase-2: lowercase, hyphen, on main, after the last merge
ISOM 472: Project in IS — Kuwait University

How Phase 2 is read — the group part

  • The ledger: present, current, plausible — or zero. Binary. No arithmetic.
  • Every other row on the checklist is read at one of three levels: not there · there with gaps · meets
  • Meets is the "done means" column. Nothing above it earns extra.
  • Workflow slips are warnings, not deductions — approving in ten seconds, merging your own work, signing for a teammate. They are recorded. Repeats cost later.
  • The cutoff is the tag. Work after it is recorded, not marked, and still required.

Full rubric on the course site, deliverables page.

ISOM 472: Project in IS — Kuwait University

How Phase 2 is read — your own part

  • Your named stories and their criteria — written by you, assigned to you, criteria a teammate can check
  • The quiz — Quiz 3 today, and the quiz that follows each sprint, answered on your phone

If it is not in the repository under your account, it is not yours.

ISOM 472: Project in IS — Kuwait University

Before you leave — check your own repository

  • Open the Phase 2 checklist on the course site
  • For each row: is it in your repository, and who finishes it?
  • Stories, criteria, schema, then screens. Not the other way round.

Open Phase 1 conditions come first. Then this.

ISOM 472: Project in IS — Kuwait University

Read — agent safety

  • Agent safety and the sandbox — on the course site
  • malmarz.github.io/isom472/week-04/agent-safety/
  • It replaces the lecture
  • Required reading for Phase 2
ISOM 472: Project in IS — Kuwait University

Quiz 3 — now

Answered on your phone.

ISOM 472: Project in IS — Kuwait University

The first class of week 4. About 45 minutes of teaching — roughly 15 on roles, 18 on one story walked live in the example repository, 10 on Phase 2 (the delivery note, the checklist, how it is read) — then Quiz 3 in the last ten minutes. Everything here should be usable at the Phase 2 delivery. The agent-safety material has moved to a reading on the course site; it is not taught from the front today.

Say the timing out loud so nobody is surprised by the quiz: it runs in the last ten minutes of this class. The middle part is the one to watch closely — it is the loop every team will repeat dozens of times from Phase 3. The third part is the one most teams need: what a finished Phase 2 looks like, and the checklist to take away.

The roles were introduced in week 1 as a list of artifacts. Today they are a chain: each role's output is someone else's input. Repeat the note — a Data Lead is not the only person who touches data, and a Build Lead is not the only person who builds. Every member still builds at least two stories end to end each sprint.

The spec says the Client Lead is the only person who accepts a story, and is expected to reject some. A Client Lead who has never rejected anything is not doing the job. At the end of each phase the Client Lead also saves a copy of the story list into docs/backlog.md. If asked who accepts a story the Client Lead built themselves: another member checks the criteria with them.

The prototype is built in Gemini Enterprise, opened in a browser and committed to the repository. Its value after Phase 2 is consistency: as five people add features, somebody has to notice when the fifth screen looks like a different application.

This one is written down in how-we-work.md: the schema changes only in a pull request that both sides of the feature read. Nobody changes a column quietly because their half was easier that way — and that includes the Data Lead. Seed data is invented; no real client names or phone numbers.

The Build Lead owns that it runs, not all the code in it. The temptation for a strong Build Lead is to become the team's merge button; the patterns slide comes back to that. "Nobody merges their own work" is one of the three collaboration rules and has no role exception.

Six-member teams only; at five it is combined with FinOps. The Quality Lead works on the running application, not on the code — use the system the way a user would and write down what breaks.

The ledger lives in the repository and is committed, not kept elsewhere. AGENTS.md tells the assistant never to edit docs/finops-ledger.md — it is written from what the team saw, not generated. It is scored as present or absent, which is exactly why it gets left to the last night.

The delivery note lives at docs/delivery-notes/phase-N.md and says what was delivered, who did what, and links to the stories. The tag is made on GitHub: Releases, Draft a new release, type phase-2, Create new tag, target main, Publish. Anything merged after the tag belongs to the next phase.

Walk the chain once with a story from the room. Each arrow is an artifact: an issue, a prototype screen, a table with a policy, a merged pull request at the public address, a bug issue, a ledger line, and the Client Lead's acceptance. The loop closes at the Client Lead, where it started — the person who wrote the story is the person who says it is done.

All four have already appeared this semester; name none of the teams. Each one breaks the record: an empty role means an artifact nobody owns; one reviewer means four members with no review activity to show; a mismatched role set means the ledger or the bug issues have no owner; and a row or signature entered by someone else is not that person's work. If your activity cannot be seen in the repository, you did not participate — and the reverse holds too: activity entered for you is not yours.

Close Part 1 here. This settles the question from the first two weeks: "nobody merges their own work" now has a named person on the other side — the reviewer who approved. It is not a role; it is whoever took the review. Every member reviews some pull requests, so every member merges some. A reviewer's comment is visible activity in the repository; a team where one person does all the reviewing has one member with evidence of review and the rest with none. The publishing guide on the course site says the same.

Switch to the browser: github.com/isom472-fall2026/example-team. Do every step live, on screen, and leave each slide up for a few seconds before switching so the room has the step in writing. About 25 minutes for Part 2 in total.

Open the template live. Point at the "Who is building this" field and assign the issue to that person, so nobody picks it up twice. Do not put a prefix or your own number in the title — GitHub gives the number, and two people inventing their own will collide. "Works well" is not a criterion; "loads in under two seconds" is.

Create the branch in GitHub Desktop: Current branch, New branch, type the name, based on main. Publish it. The most common version of "I lost my work" in week 5 is someone building a story on the wrong branch.

Make two small commits live in GitHub Desktop and show both on the website with the author's photo. The fix for the grey icon is in setup.md, step 3. The agent may commit; it may not push, open the pull request, or merge — those acts are the student's, because they are the record.

Push, then open the pull request from GitHub Desktop or the banner on the website. The template fills itself in; show the three parts. Point at the reviewer section at the bottom: the author never writes in it. Opening the pull request requests a review from every other member automatically.

Log in as a second account for this step. "Looks good" is not a review; "Opened the page, signed up with a new email, saw the confirmation, read signup.js" is. If Approve is greyed out on someone else's pull request, that member has not accepted the repository invitation — it is in their email and at github.com/notifications.

Tick the criteria in the issue as they are checked. Rejection is normal and expected; say which criterion failed, in the issue, so the builder knows what to change. Before the merge the story is not yet at the public address, so the Client Lead checks it on the builder's screen; after the merge, check it again live and reopen the issue if it fails there.

Merge live, as the reviewer account, and switch to the Issues tab to show #14 closed, then the board. Wait a minute and open the public address so the room sees it arrive. The board and the git log are compared at every phase; a board that lies is worth less than no board. Whether the board moves the card by itself depends on how the board is set up; if it does not, move it by hand.

All six are from this semester's repositories; name no team. The closed pull request is the costly one — the work looks finished on the board and never reached main. It can be reopened, which is worth showing if there is time. The last row is the one to dwell on: an approval with no words is a click, not a review, and from Phase 3 the review text itself is read.

The note is the deliverable most often left to the last night. It is the cheapest deliverable in the phase and the one that makes every other one findable; a reviewer who cannot find the schema from the note treats it as not delivered. "Present from it" settles what the delivery talk contains — the session format is on the course site, deliverables page.

Heading 1 is "what was decided", not "what was delivered", because in Phase 2 nothing runs yet. From Phase 3 the same heading reads "what works now that did not work before". The template file in the repository says the Phase 3 version; write the Phase 2 version under it. Heading 5 is where honesty earns something: a note that says "we have 31 stories, the floor is 40, the other nine are issues #33–#41 opened without criteria and are Phase 3's first job" is a better note than one that hides it.

Read the first paragraph aloud: it is four sentences and it tells you the whole design. Point at the table: every member wrote stories and every member is assigned two. That is the split, and it is what the individual mark reads. The team and the system are invented; the charity is the one used in the proposal example on the course site.

Section 5 is the one most often missing from a delivery note. It is not a confession; it is the Phase 3 plan. The full example is on the course site under the deliverables page.

Leave this up for a full minute. The last slide before the quiz sends every team back to it with their own repository open. The owner column is who I ask when the row is missing, not the only person who works on it. Three rows ask for things the repository template does not contain, so teams make them by hand: the Assignee is set with the control on the right of the issue, a typed name is not a split; the two schema files are new files the Data Lead creates, db/ does not exist yet; the "when a value is missing" line is a criterion written into the story. "Example persona deleted" is literal: a persona file that still contains the shop supervisor from the template has not been started. The two schema rows answer the question one team asked this weekend: both files, and the document is not a copy of the SQL — it says what the SQL cannot. The tag row is spelled out because two teams tagged Phase 1 with a capital P. The same table is on the course site, deliverables page.

"Three levels" is the whole rubric design: students can self-assess it against the checklist in under ten minutes. The site shows the levels; read from there. The last line is the same rule as Phase 1.

The two components are published; their weights are not. The quiz that follows each sprint is on the sprint's own work.

Two minutes, not more. Point at the checklist row by row and ask the room to answer the two questions for their own team on the way out. Say once that building before the personas and stories exist is doing the last step first; the order the rubric reads is story, criteria, schema, screens.

Run Quiz 3. Four items, answered in order; the open item is last.