diff --git a/config.yaml b/config.yaml
index 37cd3dc..d0f3c05 100644
--- a/config.yaml
+++ b/config.yaml
@@ -58,11 +58,13 @@ contact: 'icosden@princeton.edu'
 # - another-learner.md
 
 # Order of episodes in your lesson
-episodes: 
+episodes:
 - introduction.md
 - waterfall.md
 - agile.md
 - scrumban.md
+- choosing.md
+- genai.md
 
 # Information for Learners
 learners: 
diff --git a/episodes/agile.md b/episodes/agile.md
index 3e31b1f..3470834 100644
--- a/episodes/agile.md
+++ b/episodes/agile.md
@@ -35,79 +35,83 @@ They tend to incorporate other practices to improve software quality.
 We are uncovering better ways of developing software by doing it and helping others do it.
 Through this work we have come to value:
 
-- **Individuals and interactions** over processes and tools
-- **Working software** over comprehensive documentation
-- **Customer collaboration** over contract negotiation
-- **Responding to change** over following a plan
+| We value… | …over… |
+|-----------|--------|
+| **Individuals and interactions** | processes and tools |
+| **Working software** | comprehensive documentation |
+| **Customer collaboration** | contract negotiation |
+| **Responding to change** | following a plan |
 
-(Nearly) everything about Agile Development is based on one value:
-Identify and eliminate sources of **WASTE**.
+Note the phrasing: the items on the right still have value — the items on the left
+just have *more*. (Nearly) everything about Agile is based on one underlying value:
+identify and eliminate sources of **WASTE**.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## Agile does not mean "no plan, no docs"
+
+A common misconception is that Agile means skipping planning and documentation.
+It doesn't. Agile teams plan constantly — just in shorter cycles — and they write
+the documentation that genuinely helps. The shift is *when* and *how much*, not
+*whether*.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
 
 ### Individuals and Interactions over Processes and Tools
 
-Good processes and tools are important, but it's more important to make
-sure that people are happy, productive, and communicating.
-If a process or tool isn't working for people, change it!
-Agile methods favor lightweight, widely accessible tools over fancy, expensive software packages.
-This can mean collaborative whiteboards in public areas and simple text formats
-like markdown and restructuredText for documents.
-Agile methods promote a pace for software development that can be
-sustained indefinitely and without heroics.
-
-Agile methods incorporate very regular communication of status, identification of
-issues, and retrospectives/postmortems on efforts.
-This is preferably in face-to-face interactions like daily interactions between
-software developers.
-Planning and retrospective discussions are usually held every 1-4 weeks.
-
-Agile methods also respect the time of individuals.
-Meetings are time-boxed so that software developers can focus on the problems they are solving.
-Daily status meetings are kept to 15 minutes and planning meetings are kept to 1
-hour per week of development effort.
+- People come first: keep them happy, productive, and communicating. If a process
+  or tool isn't working for people, **change it**.
+- Favor lightweight, accessible tools over fancy, expensive packages.
+- Communicate status, issues, and lessons learned **regularly** — ideally face-to-face.
+- Protect people's time: meetings are **time-boxed** so developers can focus.
+
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## What this looks like in practice
+
+- Shared whiteboards and simple text formats (Markdown, reStructuredText) over heavy tooling.
+- Daily status meetings kept to **15 minutes**.
+- Planning kept to about **1 hour per week** of development effort.
+- A pace that can be sustained indefinitely — **without heroics**.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
 ### Working Software over Comprehensive Documentation
 
-Requirements specifications and design documents have one main purpose:  to
-help get to useful, working software.
-Customers generally don't care about them once they have their software!
+The purpose of specs and design docs is to help get to useful, working software —
+customers generally don't care about them once they have what they need. So Agile
+teams keep **"just barely enough"** documentation: enough to develop, use, and
+maintain the project, and no more. Good docs capture the **"big picture"** and the
+**"why?"** — the things you *can't* easily figure out by reading the code.
 
-Agile methods generally maintain only documentation that allows the project to
-be developed, used, and maintained, and nothing more.
-A common agile approach is "just barely enough" documentation.
-The documentation should focus on what developers can't easily figure out looking
-at the code, i.e., the "big picture," and "why?" rather than "what?"
-Work should be completed "at the latest responsible moment."
-Guards should be implemented to prevent wasted work from changing requirements.
+::::::::::::::::::::::::::::::::::::::::::  callout
 
-Agile methods generally use lightweight representations for software requirements,
-UI designs, software architecture/design, etc.:
+## Lightweight representations
 
-- a whiteboard sketch of a UI workflow or domain model
-- a 3x5 card with a brief user story described on it
-- GitHub Issues to capture feature requests as well as bugs
+- A whiteboard sketch of a UI workflow or domain model
+- A 3x5 card with a brief user story on it
+- GitHub Issues to capture feature requests and bugs
 
-### Customer Collaboration over Contract Negotiation
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
-If "contract negotiation" really means:  "Give me a specification of what you
-want, then leave me alone so I can go get it done," there might be a problem.
-This can occur between team members, as well as between a team and its client,
-and tends to make processes less flexible and adaptable to change.
-Agile expects requirements, or the understanding of requirements, to change!
+### Customer Collaboration over Contract Negotiation
 
-Agile methodology encourage constant collaboration within teams, and between
-developers and clients, to ensure that everyone's needs and goals are being met.
-Some agile approaches do limit opportunities for requirements to change in order
-to reduce what is called "requirements churn."
+"Contract negotiation" can quietly become: *"Give me a spec of what you want, then
+leave me alone to go build it."* That makes a project less flexible — and Agile
+**expects** requirements (or our understanding of them) to change. Instead, Agile
+encourages constant collaboration within the team and with clients so everyone's
+needs and goals stay aligned. Some approaches do deliberately limit *when*
+requirements can change, to reduce **"requirements churn."**
 
 ### Responding to Change over Following a Plan
 
-When requirements change, the current plan may no longer be the right plan.
-Agile methods adapt to change by reviewing and revising plans iteratively, over short time periods.
-Agile methods tend to only have detailed plans for the short- to medium-term.
-If (when) changes come, any effort spent on detailed long-term plans would have been wasted.
+When requirements change, the current plan may no longer be the right plan. Agile
+teams adapt by reviewing and revising plans **iteratively, over short time periods**,
+and only plan the short- to medium-term in detail. Any effort spent on detailed
+long-term plans is wasted as soon as things change — and they will.
 
 
 Now you know more about the theory around the Agile Methodology.
diff --git a/episodes/choosing.md b/episodes/choosing.md
new file mode 100644
index 0000000..be36e51
--- /dev/null
+++ b/episodes/choosing.md
@@ -0,0 +1,101 @@
+---
+title: "Choosing a Methodology"
+teaching: 5
+exercises: 2
+---
+
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Compare the Waterfall model and Agile approaches side by side.
+- Identify the factors that make one methodology a better fit than another.
+- Recognize that real projects often blend approaches.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- How do Waterfall and Agile compare?
+- Which factors should guide my choice of methodology?
+- Do I have to pick just one?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## Two Ends of a Spectrum
+
+You've now seen the Waterfall model and Agile frameworks like Scrum and Kanban.
+It's tempting to ask "which one is *best*?" — but the better question is "which one
+fits **this** project, **this** team, right now?"
+
+Agile does requirements gathering and design incrementally, mostly just before
+implementation. A well-executed Waterfall project can actually be *less* costly
+overall — **as long as the requirements and design don't change.** The catch, of
+course, is that they usually do.
+
+![](fig/agilevswaterfall.png){alt='A graph of project lifetime vs. effort for agile and waterfall. Waterfall has large peaks in effort at the beginning, followed by predictable iterations. Agile has smaller upfront cost but also has similar predictable iterations.'}
+
+The graph shows the trade-off: Waterfall front-loads a large planning and design
+effort, betting that it gets things right early. Agile spreads that effort out,
+accepting some ongoing cost in exchange for the ability to absorb change.
+
+## What to Weigh
+
+No single factor decides it. Look at the project as a whole:
+
+| Factor | Leans **Waterfall** | Leans **Agile** |
+|--------|---------------------|------------------|
+| Requirements clarity | Clear and complete up front | Fuzzy or still being discovered |
+| Likelihood of change | Low — stable scope | High — expect it to shift |
+| Stakeholder availability | Involved early, then hands-off | Available throughout |
+| Team size and co-location | Large, distributed, formal | Small, communicative |
+| Timeline and delivery | One big delivery at the end | Frequent, incremental releases |
+| Risk and uncertainty | Well-understood domain | Novel problem or technology |
+| Regulatory / fixed-scope needs | Strict documentation, fixed contract | Flexible scope |
+
+If most of your answers fall in the right-hand column — which is common for research
+software — an Agile approach will usually serve you better.
+
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## Research software in practice
+
+Research software rarely starts with stable requirements: the whole point is often
+to explore something nobody has built yet. That pushes most research projects toward
+Agile. But pieces of Waterfall still show up — a grant proposal is essentially an
+upfront requirements-and-design document, and a paper deadline is a fixed release
+date. Recognizing *which parts* of your project are stable and which are exploratory
+helps you apply the right approach to each.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## It's Not Either/Or
+
+In practice, very few teams run any methodology exactly as written. Hybrids are the norm:
+
+- **Waterfall-ish planning, Agile execution** — do enough upfront design to satisfy
+  a grant or stakeholders, then build iteratively in sprints.
+- **Scrumban** — Scrum's cadence with Kanban's flexible flow.
+- **Phase-appropriate** — a stable, well-understood component might be built
+  Waterfall-style while an experimental one is developed iteratively.
+
+The methodologies are tools, not identities. Borrow what helps and drop what gets in
+the way — which is itself a very Agile thing to do.
+
+::::::::::::::::::::::::::::::::::::::::::  discussion
+
+## Which fits your project?
+
+Think of a software project you're actually working on (or about to start).
+
+- Where do its requirements fall on the clarity/change spectrum?
+- Which approach — or blend — would fit best?
+- What's one practice from this lesson you could adopt right away?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- There's no universally "best" methodology — only right-sized for a given project, team, and moment.
+- Requirements clarity and likelihood of change are the biggest factors; stable scope favors Waterfall, change favors Agile.
+- Most research software leans Agile, but real projects commonly blend approaches.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
diff --git a/episodes/genai.md b/episodes/genai.md
new file mode 100644
index 0000000..6a59d56
--- /dev/null
+++ b/episodes/genai.md
@@ -0,0 +1,105 @@
+---
+title: "GenAI in Project Management"
+teaching: 5
+exercises: 0
+---
+
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Identify practical ways generative AI can support project management tasks.
+- Recognize the risks and limitations of using genAI in a project workflow.
+- Understand special considerations for using genAI in research software.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- Where can generative AI genuinely help with project management?
+- What are the risks of relying on it?
+- What should research software engineers keep in mind?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## A New Tool in the Toolbox
+
+Generative AI — large language models (LLMs) like ChatGPT, Claude, and others — has
+quickly become part of many developers' daily workflow. These tools are good at
+working with *text*, and a surprising amount of project management **is** text:
+user stories, backlogs, meeting notes, status updates, documentation.
+
+Used well, genAI can take the friction out of the routine writing-and-organizing
+parts of project management, freeing you to spend time on the parts that need human
+judgement. Used carelessly, it can introduce confident-sounding mistakes and erode
+the very communication that good project management depends on.
+
+## Where It Helps
+
+| Task | How genAI can help |
+|------|--------------------|
+| **Drafting user stories** | Turn a rough feature idea into well-formed "As a... I can..." stories |
+| **Breaking down epics** | Suggest how to decompose a large feature into sprint-sized tasks |
+| **Backlog generation** | Brainstorm candidate features or edge cases you might have missed |
+| **Estimation support** | Surface considerations that affect complexity (a starting point, not the answer) |
+| **Summarizing** | Condense standup notes, long issue threads, or a sprint's activity |
+| **Retrospectives** | Cluster feedback into themes and suggest action items |
+| **Documentation** | Draft READMEs, docstrings, changelogs, and "how to contribute" guides |
+| **Communication** | Rephrase a technical update for a non-technical stakeholder |
+
+The common thread: genAI is best as a **fast first draft** and a **brainstorming
+partner**, as long as you then review, correct, and own.
+
+## Where to Be Careful
+
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## Keep a human in the loop
+
+- **Hallucination.** LLMs can produce plausible, fluent, and *wrong* output —
+  invented requirements, mis-estimated tasks, fabricated references. Always verify.
+- **False confidence.** The polished tone makes errors easy to miss. Treat output as
+  a draft from an eager junior colleague, not an authority.
+- **Eroding communication.** Agile values *individuals and interactions*. If an
+  AI-summarized standup replaces the team actually talking, you've optimized away the
+  point of the meeting.
+- **Data, privacy, and IP.** Anything you paste into a third-party tool may leave your
+  control. Don't share confidential, sensitive, or proprietary information without
+  knowing the tool's data policy.
+- **Accountability stays human.** The AI doesn't own the deadline, the bug, or the
+  stakeholder relationship — you do.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## For Research Software Specifically
+
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## Research considerations
+
+- **Reproducibility and provenance.** If genAI shaped your plan, design, or docs, keep
+  a record of how. Reproducibility is a core value of research software.
+- **Disclosure.** Many journals, funders, and institutions now have policies on
+  disclosing AI use. Check them before you rely on AI-generated content in outputs.
+- **Sensitive and unpublished data.** Unpublished results, participant data, and
+  embargoed work generally should **not** go into external AI tools.
+- **Grant and reporting language.** GenAI can help draft progress reports and broader-
+  impacts text — but you remain responsible for accuracy and for meeting the funder's
+  expectations.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## The Bottom Line
+
+GenAI is a genuinely useful project-management assistant for the routine, text-heavy
+work — drafting, summarizing, brainstorming, reorganizing. It is **not** a substitute
+for the human judgement, communication, and accountability that make a project
+succeed. The teams that benefit most are the ones who already understand good project
+management, and use AI to do it faster — not to avoid doing it at all.
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- GenAI excels at the text-heavy parts of project management: drafting stories, summarizing, and brainstorming.
+- Always verify AI output — hallucination and false confidence are real risks, and accountability stays with you.
+- For research software, mind reproducibility, disclosure policies, and never share sensitive or unpublished data with external tools.
+- GenAI augments good project management; it doesn't replace human judgement.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
diff --git a/episodes/introduction.md b/episodes/introduction.md
index 1711bc1..b651aeb 100644
--- a/episodes/introduction.md
+++ b/episodes/introduction.md
@@ -42,6 +42,19 @@ need project management.
 
 _But are you sure it's really just "one week"?_
 
+::::::::::::::::::::::::::::::::::::::::::  callout
+
+## Project management for research software
+
+Research software has its own flavor of these questions. The "customer" might be your
+PI, your grant's aims, a collaborating lab, or simply **"future you"** trying to
+reproduce a result. "Release" might mean tagging a version for a paper, and
+"maintenance" might mean keeping code runnable long after the student who wrote it
+has graduated. Even a one-person project benefits from a little structure once it
+needs to outlive a single deadline.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
 :::::::::::::::::::::::::::::::::::: challenge
 
 ## When do you need it?
@@ -54,15 +67,17 @@ What are some situations in which it might not be necessary?
 
 ## Software Development Process
 
-Below are (most) of the different phases of the software development process. 
+Below are (most) of the different phases of the software development process.
 
-1. Determine software requirements
-2. Software design 
-3. Implementation
-4. Software testing
-5. Software documentation
-6. Release/deploy the software to the customer 
-7. Ongoing maintenance
+| # | Phase | What happens | Typical output |
+|---|-------|--------------|----------------|
+| 1 | Requirements | Figure out what the software needs to do | A list of needs / user stories |
+| 2 | Design | Decide how it will be built | Architecture, interfaces, plans |
+| 3 | Implementation | Write the code | Working code |
+| 4 | Testing | Confirm it does what it should | Tests, bug reports |
+| 5 | Documentation | Explain how to use and maintain it | User and developer docs |
+| 6 | Release / Deploy | Get it to the people who use it | A usable version |
+| 7 | Maintenance | Keep it working and fix issues over time | Patches, updates |
 
 These phases can be mixed or (sometimes) reordered.
 This can happen for a variety of reasons.
@@ -73,8 +88,13 @@ Another thing to note is that the definition of roles vary.
 For example, the "customer" or "user" may also be the author of the software, or may be quite removed.
 
 There are many different methodologies to help organize the software development process.
-In the following sections, we will discuss some of the more popular methodologies
-such as the Waterfall model and Agile software development.
+In the rest of this lesson we will work through them in order:
+
+1. **The Waterfall model** — phases done sequentially
+2. **The Agile methodology** — iterative and responsive to change
+3. **Agile frameworks** — Scrum, Kanban, and MoSCoW in practice
+4. **Choosing a methodology** — how to decide which fits your project
+5. **GenAI in project management** — where LLMs help, and where they don't
 
 
 :::::::::::::::::::::::::::::::::::::::: keypoints
diff --git a/episodes/scrumban.md b/episodes/scrumban.md
index 7f78173..35fc2c9 100644
--- a/episodes/scrumban.md
+++ b/episodes/scrumban.md
@@ -1,7 +1,7 @@
 ---
 title: "Agile Development"
-teaching: 5
-exercises: 45
+teaching: 20
+exercises: 35
 ---
 
 ::::::::::::::::::::::::::::::::::::::: objectives
@@ -25,6 +25,24 @@ Scrum is a lightweight process that aims to break work into time-boxed iteration
 
 ![](fig/scrum-process.png){alt='The Scrum Process - an interative process that flows from Product goal to Sprint planning to development (in increments) to Sprint review, looping back'}
 
+::::::::::::::::::::::::: callout
+
+## Who's who in Scrum
+
+Scrum defines three roles. It helps to map them to today's exercise:
+
+| Role | Responsibility | In our exercise |
+|------|----------------|-----------------|
+| **Product Owner** | Owns the vision and prioritizes the backlog; represents the customer | The "customer" |
+| **Scrum Master** | Keeps the process running, removes blockers, protects the team | A designated member of your group |
+| **Development Team** | Builds the product; estimates and commits to the work | Your group |
+
+In research software these roles often blur — a PI might be the Product Owner, and
+a single developer may wear all three hats. The *responsibilities* still need an owner,
+even if the titles don't.
+
+:::::::::::::::::::::::::::::::
+
 ### Project Vision
 
 In the initial phase, project envisioning takes place.
@@ -77,6 +95,23 @@ to the product roadmap, risk/uncertainty, level of difficulty, etc.
 Implementation cost of the features is determined by the developers.
 The developers then commit to completing those tasks within the sprint.
 
+::::::::::::::::::::::::: callout
+
+## Estimating the work
+
+How do developers figure out "implementation cost"? Rather than guessing exact hours,
+Agile teams usually estimate *relative* effort:
+
+- **Story points** — an abstract size (often Fibonacci: 1, 2, 3, 5, 8...) capturing
+  effort, complexity, and uncertainty together.
+- **Planning poker** — everyone privately picks an estimate, then reveals
+  simultaneously; big disagreements spark a useful discussion before re-voting.
+- **T-shirt sizes** — quick, coarse sizing (S / M / L / XL) when points feel like overkill.
+
+The goal is to create a shared understanding of how much fits in a sprint.
+
+:::::::::::::::::::::::::::::::
+
 :::::::::::::::::::::: callout
 
 ## Defining the Work
@@ -101,6 +136,16 @@ They meet for daily stand-up meetings (generally 15 minutes) in which they discu
 what they did yesterday, what they plan to do today, and any blockers or issues
 that may have occurred.
 
+::::::::::::::::::::::::: callout
+
+## Definition of Done
+
+Teams agree up front on what **"done"** actually means — for example: code written,
+tests passing, reviewed, and documented. A shared *Definition of Done* keeps "done"
+from quietly meaning "works on my machine," and makes sprint reviews honest.
+
+:::::::::::::::::::::::::::::::
+
 ### Sprint Review
 
 At the end of the sprint is a sprint demo and a retrospective discussion.
@@ -113,39 +158,63 @@ had to be dealt with and what can be done better in future sprints.
 A sprint may include releasing/deploying software, or it may not. 
 This depends on where the team is with respect to the product roadmap.
 
-## Agile vs. Waterfall
-
-Agile does requirements gathering and design incrementally, mostly just before implementation.
-Overall, Agile may be more costly than a well-executed waterfall approach, as
-long as requirements and design don't change!
-
-![](fig/agilevswaterfall.png){alt='A graph of project lifetime vs. effort for agile and waterfall. Waterfall has large peaks in efforts at the beginning, followed by predictable iterations. Agile has smaller upfront cost but also has similar predictable iterations.'}
-
 ## Other Agile Methodologies
 
 ### Kanban
 
 Japanese for "Board," Kanban is a lightweight method for tracking work on a project.
-While it was originally done using a board marked into four columns and Post-It notes,
+While it was originally done using a board marked into columns and Post-It notes,
 it integrates well with GitHub.
 Kanban is typically best for small to medium size projects.
 
 ![](fig/kanban.png){alt='Two team members addressing a Kanban board with four columns.'}
 
+Scrum and Kanban are both Agile, but they emphasize different things:
+
+| | **Scrum** | **Kanban** |
+|---|-----------|------------|
+| Rhythm | Fixed-length sprints | Continuous flow |
+| Roles | Defined (PO, Scrum Master, team) | No required roles |
+| Change | Wait for next sprint | Add anytime |
+| Best for | Coordinating a team toward releases | Steady streams of incoming work |
+
+These aren't mutually exclusive — combining them is exactly what **Scrumban** (the
+upcoming exercise) is about.
+
 ### MoSCoW
 
-MoSCoW is a lightweight technique for prioritizing work typically done in the sprint planning meeting.
-This meeting's focus is on the next software release/sprint.
+MoSCoW is a lightweight technique for prioritizing work, typically done in the sprint
+planning meeting with a focus on the next release/sprint:
+
+| Category | Meaning |
+|----------|---------|
+| **Must have** | Without this, we don't have a usable release |
+| **Should have** | Important, but the release still works without it |
+| **Could have** | Nice to have, not essential |
+| **Won't have** | Not this time (maybe never) |
+
+Work first on **Must haves**, then **Should haves** if time remains in the sprint.
+
+:::::::::::::::::::::::::::::::::::::: callout
+
+## Which methodology should you use?
+
+We've now seen Waterfall and several Agile frameworks. How do they compare, and
+how do you choose between them for a real project? That's the focus of the next
+episode, **Choosing a Methodology**.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::: instructor
 
-MoSCoW stands for:
+## Suggested break point
 
-- **Must have**: Without this, we don't have a useable release
-- **Should have**: The release would be less valuable or compelling without this, but would still be worth releasing
-- **Could have**: Nice to have, but not essential
-- **Won't have**: Maybe not ever, but too much for this time
+If you teach this lesson in two parts, this is the natural place to take your break.
+Session 1 ends here (Introduction through the Scrum/Kanban/MoSCoW theory); the
+Scrumban exercise below opens Session 2 while attendees are fresh, since it needs an
+uninterrupted block of time to succeed. See the Instructor Notes for the full schedule.
 
-The priority of the sprint is to work first on **Must Haves** and then **Should Haves** (if there
-is time remaining in the sprint).
+::::::::::::::::::::::::::::::::::::::
 
 ::::::::::::::::::::: challenge
 
@@ -161,13 +230,13 @@ called Scrumban! In this exercise, you will be using LEGOs :tm: to build a car.
 2. (4 min) Project backlog: Create a Kanban board for your project on one of the walls near you
    with the columns "To Do", "In Progress", and "Done". Create your "backlog" by writing the features
    or work to be done on the sticky notes and putting them in the "To Do" column.
-3. (2 min) Sprint planning: Decide what work will be completed this sprint. Move those sticky notes
-   to the "In Progress" column.
-4. (5 min) Sprint work: **BUILD**!
-5. (3 min) Sprint review: Show what you have to your customer and get feedback. Make changes to
+3. (2 min) Sprint planning: Decide what work will be completed this sprint. Prioritize your
+   backlog (try MoSCoW!) and move the sticky notes you commit to into the "In Progress" column.
+4. (4 min) Sprint work: **BUILD**!
+5. (2 min) Sprint review: Show what you have to your customer and get feedback. Make changes to
     your Kanban board as necessary (e.g., move completed work to "Done", adjust work in "To Do" if
     need be).
-6. Repeat steps 3-5 two more times!
+6. Repeat steps 3-5 two more times! (Three sprints total, ~8 min each.)
 
 :::::::::: instructor
 
@@ -193,9 +262,11 @@ Instructions to give to the customers:
 > should then start asking you questions about the house: "How many wheels? How many
 > windows and doors?" (etc. etc.) They don't get as much time for this - only 4 minutes.
 > Then they go through a Kanban board task writing / backlog creation stage for 4 minutes.
-> They will then do a "sprint" / iteration and try to get something created in the next few minutes.
-> They bring it back to you. You tell them what's right / wrong. They adjust their
-> Kanban board / plan their "sprint" (repeat for three total iterations).
+> They will then do a "sprint" / iteration (about 8 minutes each: 2 min plan, 4 min build,
+> 2 min review) and try to get something created. They bring it back to you. You tell them
+> what's right / wrong. They adjust their Kanban board / plan their next "sprint" (repeat for
+> three total iterations). The slightly longer planning time is intentional — prioritizing
+> and re-planning between sprints is the core skill this exercise teaches.
 
 :::::::::::::::::::::
 
@@ -207,8 +278,8 @@ How was that experience? What did you like? What did you dislike?
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
-That's it, folks! You now have knowledge of different project management methods
-for software projects.
+You now have hands-on experience with both ends of the methodology spectrum. Next,
+we'll look at how to **choose** between them.
 
 :::::::::::::::::::::::::::::::::::::::: keypoints
 
diff --git a/episodes/waterfall.md b/episodes/waterfall.md
index 935d9db..65a8608 100644
--- a/episodes/waterfall.md
+++ b/episodes/waterfall.md
@@ -1,7 +1,7 @@
 ---
 title: "The Waterfall Model"
 teaching: 5
-exercises: 30
+exercises: 25
 
 ---
 
@@ -53,10 +53,10 @@ we will consider the phases to be:
 ![](fig/house.png){alt='A house icon - created by VectorMachines on Flaticon.'}
 
 0. Split into 4 groups and grab a set of LEGOs :tm:.
-1. (7 min) Gather requirements from your customer. 
+1. (6 min) Gather requirements from your customer.
    Ask important questions to help you determine what needs to be done to build their dream house!
-2. (5 min) Determine your design. How can you satisfy the requirements with your LEGOs?
-3. (12 min) Build the house!
+2. (4 min) Determine your design. How can you satisfy the requirements with your LEGOs?
+3. (10 min) Build the house!
 4. (3 min) Show it to your customer and see how you did.
 
 :::::::::: instructor
@@ -83,7 +83,7 @@ Instructions to give to the customers:
 > should then start asking you questions about the house: "How tall? How many
 > windows and doors?" (etc. etc.) They have 6 minutes to gather the requirements.
 > Then they aren't allowed to talk to you again while they build the house.
-> After 12 minutes of design and implementation, they show you their "completed"
+> After their design and implementation, they show you their "completed"
 > house. You provide feedback on what is wrong, what is right, etc.
 
 :::::::::::::::::::::
@@ -118,18 +118,21 @@ than to fix a requirement after implementation." - Boehm and Papaccio, 1988
 ::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
 
-The Waterfall model works well when:
+When does Waterfall shine, and when does it struggle?
 
-- Software requirements are very clear, well understood, and unchanging
-- Technical implementation details are also very well understood (generally 
-  considered more suited to manufacturing, but this is also changing with rapid prototyping!)
+| Works well when… | Works poorly when… |
+|------------------|--------------------|
+| Requirements are clear, well understood, and unchanging | Requirements are vague or likely to change |
+| Technical implementation is well understood | The technology or approach is new/uncertain |
+| The end goal is fixed and predictable | Discovery and learning are part of the work |
 
-Inversely, waterfall model works terribly when these things aren't present and
-can lead to greatly exceeding time and financial budgets.
-Waterfall-based models don't handle lack of knowledge, or change, very effectively.
-Poorly understood or changing software requirements, technology, or
-architecture choices can negatively impact the performance of the waterfall-model.
-Though, it should be noted that a lack of software-engineering discipline virtually negates all approaches.
+When the left-hand conditions aren't met, Waterfall can lead to greatly exceeding
+time and financial budgets — it doesn't handle lack of knowledge, or change, very
+effectively. (This is more suited to manufacturing, though even that is changing with
+rapid prototyping!)
+
+That said, a lack of software-engineering discipline virtually negates *all*
+approaches — no methodology rescues a project with no process at all.
 
 :::::::::::::::::::::::::::::::::::::::: keypoints
 
diff --git a/instructors/instructor-notes.md b/instructors/instructor-notes.md
index d9a67aa..18ce3b1 100644
--- a/instructors/instructor-notes.md
+++ b/instructors/instructor-notes.md
@@ -2,4 +2,58 @@
 title: 'Instructor Notes'
 ---
 
-This is a placeholder file. Please add content here. 
+## Timing and Schedule
+
+This lesson is designed to fit a **2-hour slot taught in two parts**:
+
+- **Session 1 — 75 min**
+- **Break — 15 min**
+- **Session 2 — 45 min**
+
+The two LEGO :tm: exercises (house in Waterfall, car in Scrumban) are the heart of
+the lesson and need uninterrupted time. The schedule is built around
+them: the Waterfall build sits early in Session 1, and the Scrumban build opens
+Session 2 (right after the break) so attendees tackle it while fresh.
+
+### Session 1 (75 min)
+
+| Time | Segment | Notes |
+|------|---------|-------|
+| ~10 min | **Introduction** | Definition, who needs PM, SDLC phases, "When do you need it?" brainstorm |
+| ~30 min | **The Waterfall Model** | ~5 min theory + the **Build a House** exercise (22 min) |
+| ~10 min | **The Agile Methodology** | Manifesto + four values (no exercise) |
+| ~20 min | **Agile Development (theory only)** | Scrum, roles, estimation, Kanban, MoSCoW — **stop before the Scrumban exercise** |
+| | **— BREAK (15 min) —** | Break here, at the marked point before the Scrumban exercise |
+
+### Session 2 (45 min)
+
+| Time | Segment | Notes |
+|------|---------|-------|
+| ~35 min | **Scrumban exercise** | The **Build a Car** exercise: vision + backlog + three ~8-min sprints |
+| ~5 min | **Choosing a Methodology** | Comparison table, hybrids, quick discussion |
+| ~5 min | **GenAI in Project Management** | Wrap-up discussion; light if time is short |
+
+### Running tight on time?
+
+- The **GenAI** episode is discussion-based and the easiest to compress or assign as
+  a follow-up.
+- In the **Choosing** episode, the "Which fits your project?" discussion can be shortened
+  to a single show-of-hands question.
+- Do **not** cut time from the two LEGO builds — they are the point of the session.
+  If you must trim, take it from the Waterfall *build* step (the failure reveal, not a
+  polished house, is what teaches) before touching the Scrumban sprint loop.
+
+## Exercise Timing Details
+
+**Build a House (Waterfall):** 6 min requirements + 4 min design + 10 min build +
+3 min review = 23 min. Customers describe their house *without showing the picture*;
+attendees may not talk to the customer once building begins.
+
+**Build a Car (Scrumban):** 4 min vision + 4 min backlog, then three sprints of
+~8 min each (2 min plan / 4 min build / 2 min review) = 32 min. The deliberately
+longer planning step is where the methodology lives — prioritizing and re-planning
+between sprints is the skill being practiced, more than the building itself. Customers
+stay available between sprints for feedback.
+
+Both exercises use two customers with different target images (assign two groups
+each) so attendees see how identical requirements lead to different results.
diff --git a/learners/reference.md b/learners/reference.md
index 371dd41..16fbbda 100644
--- a/learners/reference.md
+++ b/learners/reference.md
@@ -1,3 +1,87 @@
-## References
+---
+title: 'Glossary and References'
+---
 
-FIXME
+## Glossary
+
+[Agile]{#agile}
+: A family of iterative software development methodologies that respond to change,
+favoring working software and close collaboration over heavy upfront planning.
+
+[Backlog]{#backlog}
+: The prioritized list of all work (features, user stories, bugs) remaining on a project.
+
+[Backlog grooming]{#backlog-grooming}
+: Periodic review of the backlog to refine, re-prioritize, and remove items that are
+no longer relevant.
+
+[Definition of Done]{#definition-of-done}
+: A shared, agreed-upon checklist of what must be true for a piece of work to count as
+complete (e.g., coded, tested, reviewed, documented).
+
+[Epic]{#epic}
+: A large feature that spans multiple sprints; it is broken down into smaller user
+stories.
+
+[Kanban]{#kanban}
+: A lightweight Agile method that visualizes work as cards moving through columns
+(e.g., "To Do", "In Progress", "Done") in a continuous flow.
+
+[Minimum Viable Product (MVP)]{#mvp}
+: The smallest release that delivers real value and can be used and evaluated.
+
+[MoSCoW]{#moscow}
+: A prioritization technique sorting work into Must have, Should have, Could have, and
+Won't have.
+
+[Product Owner]{#product-owner}
+: The Scrum role that owns the product vision and prioritizes the backlog, representing
+the customer.
+
+[Requirements churn]{#requirements-churn}
+: Repeated, costly changes to requirements during development.
+
+[Retrospective]{#retrospective}
+: A meeting at the end of a sprint where the team reflects on what went well and what to
+improve.
+
+[Roadmap]{#roadmap}
+: A planned series of releases mapping backlog features to future delivery points.
+
+[Scrum]{#scrum}
+: A widely used Agile framework that organizes work into fixed-length sprints with
+defined roles and ceremonies.
+
+[Scrum Master]{#scrum-master}
+: The Scrum role responsible for facilitating the process and removing blockers for the
+team.
+
+[Scrumban]{#scrumban}
+: A hybrid approach combining Scrum's cadence with Kanban's flexible, visual flow.
+
+[Sprint]{#sprint}
+: A time-boxed development iteration (typically 1–4 weeks) producing a potentially
+shippable increment.
+
+[Standup]{#standup}
+: A short (~15 min) daily meeting where the team shares progress, plans, and blockers.
+
+[Story points]{#story-points}
+: A relative, abstract measure of the effort/complexity of a piece of work, used for
+estimation.
+
+[User story]{#user-story}
+: A short description of a feature from a user's perspective, e.g., "As a user, I can
+view my data."
+
+[Waterfall]{#waterfall}
+: A sequential methodology where each phase (requirements, design, implementation,
+verification, maintenance) is completed before the next begins.
+
+## References and Further Reading
+
+- [The Agile Manifesto](https://agilemanifesto.org/)
+- [Project Management Institute — What is Project Management?](https://www.pmi.org/about/learn-about-pmi/what-is-project-management)
+- Boehm, B. and Papaccio, P. (1988). "Understanding and Controlling Software Costs."
+  *IEEE Transactions on Software Engineering.* (Source of the "50x–200x" requirements-cost figure.)
+- [The Scrum Guide](https://scrumguides.org/)