Case Study: Writing an EPIC with Claude Code

Recurring Course Assignment — a real session walkthrough showing the iterative approach

What This Shows

This is a walkthrough of a single Claude Code session that produced the EPIC document for the Recurring Course Assignment feature. The session demonstrates three patterns worth adopting:

Set an agenda — scope what fits in one session, don't try to do everything
Iterate section by section — draft, get feedback, revise, approve, then move on
Use Claude's tools — pull data from Jira, explore the codebase, save context for next time

Starting with an Agenda

The session started by laying out everything to accomplish, then scoping what fit:

Brief Claude on the updated approach
Create EPIC document
Think through reporting impact (captured in EPIC)
Reconcile with existing admin UI (separate session)
Create Stories in Jira (separate session)

Items 4 and 5 were deferred to separate sessions — different modes of work (see phases). The agenda kept us focused: when the EPIC was done, we knew to stop rather than drift into UI design.

Briefing Claude on Changes

This was a continuation of a multi-session project. The prior design had 13 system components covering three use cases. The updated approach simplified radically — but Claude had the old context in memory. The PM walked through what changed:

PM Components need to be reconsidered. We are not going to build some of them in V1. Admin UX Design needs to be redone. Won't have single schedule principle. Story breakdown and build sequence need to be updated. Model comparison may not be relevant. The solution is a combination of the two. Scope boundaries are out of date. New scope will be more restrictive.

Claude Here's the updated v1 as I understand it: [laid out the 5-capability model with Active/Inactive, dynamic LP progress, auto-assign, "Use for Next Cycle", and newcomer skip]. Does this capture the updated approach accurately?

PM This is it.

Pattern: Confirm understanding before writing.

Claude summarized back in a structured format. The PM confirmed before any document writing started. This prevents building on a misunderstanding.

Stress-Testing Your Own Thinking

The PM had an architectural insight — Active/Inactive is the foundational primitive, and v2 scheduling rules are just automated triggers for the same state transition. The PM asked Claude to argue against it:

PM What's your argument against my instinct? What's the gaps in my thinking?

Claude The main gap: Active/Inactive in v1 is per-component (LP-wide). UC2 needs it per-learner. [Detailed 3 secondary concerns about missing states, semantic divergence, and workflow assumptions]

PM Even in v1, the execution of "active" rule is at the individual user's assignment level. We set up audiences, but tasks are set up for individual audience members. So it does reach into per-assignment.

Claude You're right — I overstated the gap. The task generation is already per-assignment in v1. The v2 shift is only in what triggers the evaluation, not in how it executes.

Pattern: Ask Claude to challenge you, then correct its challenge.

This exchange sharpened the argument. Claude raised a valid-sounding concern (per-component vs per-learner cardinality), the PM corrected it with domain knowledge (execution is already per-assignment), and they arrived at a stronger framing than either started with. The resulting insight made it into the EPIC document.

Using Existing Work as a Template

Rather than inventing a document structure, the PM pointed Claude to an existing EPIC (Custom Themes) and asked it to follow that structure. Claude read the file, extracted the pattern, and proposed an outline:

Feature Overview
Business Case
Known Use Cases and Considerations
Key Decisions and Concepts
Workflow Overview
Feature Breakdown
Reporting Considerations
Scope: V1 vs. After V1
Supporting Assets

The PM then added what was missing: a before/after comparison table and a reporting section for topics to discuss with the PM for Analytics. The outline was agreed before writing began.

Section-by-Section Iteration

This is the core of the workflow. Claude drafts one section at a time. The PM reviews, gives specific feedback, Claude revises, the PM approves, and they move on. Never write the whole document then review — errors compound.

Example: Feature Overview

Feature Overview — Draft 1 Draft

Claude's first draft included "track completion outside the system" and ended with "deliver the annual compliance workflow immediately."

PM "Track completion outside the system" is not accurate. There's no easy way to track different cycles together. When using acronyms, always spell out the first time. Don't need to say "The LP model doesn't support it." "This feature introduces" should be reframed as how admins manage and how learners experience. The last sentence — don't need "immediately," that's too boastful.

Feature Overview — Final Approved

Revised to frame around admin and learner experience. Acronyms spelled out. Accurate problem description. Confident but not boastful tone.

Pattern: Give specific, actionable feedback.

Each correction was concrete: "this phrase is inaccurate," "reframe from this angle," "remove this word." Claude can't improve on "make it better" — it needs to know what's wrong and what direction to go.

Example: Business Case

PM I would take the business case up a level. I want to touch the following points: 1. Customer retention — frequently requested, admins have voice in vendor selection, embed in essential processes. 2. New sales — sets us apart, frequently asked in RFPs, consolidating tech stacks. Do look up customers who requested in the enhancement tickets.

Claude searched the Jira enhancement board (AIS/AIT projects, type = Improvement) and found three relevant tickets with customer names: TE Connectivity, EnlivenHealth, and a group of seven customers on a course expiration request. These went directly into the Business Case section.

Pattern: Let Claude pull data while you stay in flow.

Instead of pausing to search Jira separately, the PM told Claude what to look for. Claude searched, filtered irrelevant results, and brought back customer names with ticket IDs. The PM stayed focused on the document structure.

Example: Decisions Section

The Decisions section went through multiple rounds of feedback — not on the content, but on how it was organized:

PM Maybe order differently. Scope choice first — what UC we prioritize. Then deep copy. Then active status — what does active mean, what does inactive mean. Then manual toggle.

PM #3 — not sure this is decided. It's clear we need active/inactive. But whether it's a mode on the LP needs to be decided. A new "mode" lets us isolate legacy LPs and lower regression risk. On the other hand, even existing LPs can benefit.

PM Maybe rename the section from "Decision" to something else. "Key decisions and concepts"?

Pattern: Separate content accuracy from structural feedback.

The decisions were right, but the ordering and framing needed work. The PM gave feedback in passes — reorder first, then refine individual items, then rename the section. Claude handled each pass cleanly because each was focused.

Code Investigation for Next Session

With the EPIC done, the next session would tackle UI reconciliation — how Active/Inactive fits alongside existing LP controls. The PM gave Claude screenshots of the current admin UI, and Claude searched the codebase to understand the implementation:

What Claude found

Component data model fields (startAfterDays, gatingChannelId, dueAfterDays)
Audience enrollment field (isEnrollAtPace)
All relevant JSP, JS, and Java files
How the save API validates component data

Saved for next session

Memory file with data model details
Key file paths for the LP component page
Reconciliation questions to start with
Updated context document

Pattern: End a session by setting up the next one.

Claude saves context to memory files, so the next session starts with full knowledge of what was decided, what code was found, and what questions remain. No re-briefing needed.

Session Output

One session produced:

A complete EPIC document (9 sections, ready for Google Docs)
Customer names pulled from Jira enhancement requests
Updated project context document
Code investigation notes for the next session
Memory files so the next session starts cold with full context

Patterns to Reuse

Set an agenda List everything, then scope what fits in one session. Defer items that need a different mode of work. The agenda prevents scope creep and tells you when you're done.
Confirm first After briefing Claude on something new, have it summarize back in a structured format. Confirm understanding before any writing starts.
Challenge your ideas Ask Claude to argue against your thinking. Correct its objections with your domain knowledge. The exchange sharpens both the idea and how you articulate it.
Use a template Point Claude to an existing document that has the structure you want. It extracts the pattern and proposes an outline. Add and subtract from there.
Iterate per section Never write the full document then review. Draft one section, give specific feedback ("this phrase is wrong," "reorder like this," "reframe from the user's perspective"), approve, move on.
Be specific "Make it better" doesn't help. "Don't say 'immediately' — too boastful" does. Point at the exact problem and the direction to fix it.
Let Claude pull data Jira searches, codebase exploration, competitive research — delegate the lookup, stay focused on the thinking. Tell Claude what to look for, not how to look.
Set up the next session End by saving context. Claude writes memory files so the next session starts with full knowledge of decisions, code findings, and open questions.