MVPSTUDIOSIDEAS · PRODUCTS · PEOPLE Start a conversationLet's talk
← Week 04: Assemble I: specify and brief Claude SESSION 01 · TUESDAY

Decide exactly what to build first

Turn three weeks of decisions into a story map, testable stories and a Sprint 1 backlog anyone could build from, Claude included.

STORY MAPGIVEN / WHEN / THENVERTICAL SLICESSPRINT 1
Present slides Full screen, one slide at a time · 13 slides
TONIGHT 01

By the end of tonight you will

  • Build a story map with a backbone, a walking skeleton and release slices
  • Write user stories with Given/When/Then acceptance criteria a tester could check
  • Slice work vertically and prioritise it with Kano, evidence and risk
  • Explain the Scrum accountabilities, events, artefacts and commitments
  • Agree a Definition of Done for an AI-assisted build and plan Sprint 1

OUTPUT · Story map + Sprint 1 backlog + Definition of Done in product/04-backlog.md

THE IDEA · STORY MAP 02

A story map shows the whole product at once

  1. BACKBONEThe user’s activities, left to right in order: set times, request, confirm, attend
  2. WALKING SKELETONThe thinnest row that works end to end: a learner requests, the tutor confirms
  3. RELEASE SLICESRows below, each a thin release that adds value: reminders, then rescheduling

Build the skeleton first: a thin product that works end to end beats half of a thick one.

WORKED EXAMPLE · TUTORDESK 03

A user story with acceptance criteria

Starting point

“As a user, I want booking so that it’s easier.”

Reframed

As a tutor, I want to confirm a requested slot so the learner knows the lesson is on. Given a pending request, when I press Confirm, then the learner sees ‘Confirmed’.

Ask

  • Who exactly is the user, and in what situation?
  • How would a tester know this story is done?
  • What should happen if the tutor declines instead?
  • Is it small enough to finish in a day or two?
THE IDEA · ACCEPTANCE CRITERIA 04

Given / When / Then

  1. GIVENThe starting situation: Sam has a pending request for Tuesday at 17:00
  2. WHENThe single action being tested: the tutor presses Confirm
  3. THENWhat anyone can observe: Sam sees ‘Confirmed’ and 17:00 is no longer offered
  4. ONE PER RULEA separate scenario for each rule: declined, slot already taken, slot in the past

If someone cannot check it by looking at the screen or the data, it is not yet a criterion.

THE IDEA · SLICING 05

Build in vertical slices, not horizontal layers

Horizontal layers

  • Sprint 1: every database table. Sprint 2: every screen. Sprint 3: wire it up
  • Nothing a tutor can use until every layer is finished
  • Mismatches between layers surface at the end, when they cost most

Vertical slices

  • Each slice cuts through screen, logic and data for one behaviour
  • Slice 1: a learner requests a slot and the tutor confirms it
  • Usable, testable and demonstrable to a tutor within days

A vertical slice is small enough to finish and whole enough to show a real person.

THE IDEA · PRIORITISING 06

Kano: not every feature satisfies the same way

  1. MUST-BEExpected; missing it angers users, having it goes unnoticed. Never double-book a slot
  2. PERFORMANCEThe more, the better. Fewer taps to confirm a request
  3. ATTRACTIVEUnexpected delight, not missed if absent. A ready-made lesson summary
  4. INDIFFERENTUsers do not care either way. A choice of colour themes
  5. REVERSESome users dislike having it. Reminder texts sent to every parent by default

Kano categories come from real users’ answers to paired questions, not from your guess or Claude’s.

WORKED EXAMPLE · TUTORDESK 07

The exciting-feature trap

Starting point

Start with an AI lesson planner because it demos well, before a learner can even book.

Reframed

Build the must-be first: requests that never double-book and a clear confirmation. Add the attractive feature once tutors rely on the basics, and only if tutors’ answers say it delights.

Ask

  • Which feature would a user notice only if it were missing?
  • What evidence says the exciting idea is attractive, not indifferent?
  • What would it cost you to delay it by one sprint?
THE IDEA · SCRUM ESSENTIALS 08

Scrum in one slide

  1. ACCOUNTABILITIESProduct Owner orders the backlog; Scrum Master coaches; Developers build
  2. EVENTSThe Sprint contains Sprint Planning, Daily Scrum, Sprint Review and Retrospective
  3. ARTEFACTSProduct Backlog, Sprint Backlog and the Increment: the work, made visible
  4. COMMITMENTSProduct Goal, Sprint Goal and Definition of Done: one for each artefact

Working alone you hold all three accountabilities. Claude helps with the work but is accountable for none of it.

THE IDEA · DEFINITION OF DONE 09

Definition of Done for an AI-assisted build

  1. TESTEDEach acceptance criterion has a passing automated test, and you saw it pass
  2. REVIEWEDYou read the changes and can explain them; Claude’s report matches what ran
  3. SECURENo secrets in code; a tutor sees only their own learners; input checked on the server
  4. ACCESSIBLEUsable by keyboard, labelled fields, readable contrast, errors that say what to do
  5. DOCUMENTEDProduct Book updated; committed with a message that says what changed and why

An item that fails any line goes back to the backlog, not into the demo.

CLAUDE STUDIO 10

Claude as backlog partner

Prompt for Claude
I’m building TutorDesk, a booking tool for solo tutors with 5–30 regular learners. My Product Book is in this Project; the journey and data model are in 03-design.md. I want a story map I can plan Sprint 1 from, so every item must be a vertical slice I could show a tutor.
<backbone>[PASTE YOUR BACKBONE ACTIVITIES]</backbone>
Under each activity, list user stories as “As a…, I want…, so that…”. Mark the thinnest row that works end to end as the walking skeleton. For each skeleton story, write 2–3 Given/When/Then criteria a non-technical tester could check on screen. If a story needs a decision my Product Book doesn’t cover, say so and ask me rather than choosing. Done is a table I can paste into 04-backlog.md.

Check the response

  • Every skeleton story cuts through screen, logic and data
  • Each Then is something a tester can see
  • Gaps come back as questions, not invented answers
WORKSHOP · YOUR PRODUCT 11

Story map, Sprint 1 backlog and Definition of Done

Turn your Product Book into a story map, a Sprint 1 backlog and a Definition of Done you would accept from a contractor.

  1. Write your backbone: 4–6 user activities, left to right, from your journey map (10 min)
  2. Add stories beneath, draw the walking-skeleton line, ask Claude to challenge it (15 min)
  3. Write 2–3 Given/When/Then criteria for every skeleton story (10 min)
  4. Order Sprint 1: must-bes and riskiest assumption first; write a one-line Sprint Goal (10 min)
  5. Adapt the Definition of Done; swap with a partner and check one story against it (10 min)
Deliverable

Story map, Sprint 1 backlog and Definition of Done in product/04-backlog.md

GATE 12

Backlog rubric

  • Story map shows a backbone of 4–6 user activities and a marked walking skeleton
  • Every Sprint 1 story names a specific user and why the change matters to them
  • Each Sprint 1 story has 2+ Given/When/Then criteria a partner could check on screen
  • Every Sprint 1 item is a vertical slice; no item is only a layer such as ‘database’
  • Kano labels cite real responses or are marked ‘hypothesis’; the order is explained
  • A one-line Sprint Goal and a Definition of Done with at least five checkable lines

HOMEWORK · Ask three users the Kano pair for your top two features, and try installing Claude Code before Thursday

© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms