Story Map Construction

Course Schedule

For bullet-point highlights of the spec, see the lecture slides.

NOTE: the spec remains the single source of truth: in case of any discrepancies between the slides and the spec, please follow what is written in the spec.

Using EGM to Construct a Story Map

We used the Elephant-Goldfish Model to help us scope your MDE project previously. We now continue to use it to create your Story Map.

Milestone Summarization and Context Refresh

Elephant: Feed the Elephant the selected base and stretch goals from the in-person discussion. Ask it to generate a summary of all agreed-upon constraints and features, establishing [Exhibit E-H]. Pass Exhibit E-H back to the Elephant to refresh its context.

First Draft Technical Proposal

Elephant: Using the refreshed context, ask the Elephant to propose an implementation using plain English prose and block diagrams, with minimal jargon and without generating code. Demand written text. Argue with the LLM until the approach is solid. It is IMPERATIVE that the LLM proposes the first design, to show you whether it understands your problem well.

“Based on Exhibit E-H, give me a first draft proposal of a technical implementation of a mobile app. I’m not looking for code. I want plain English prose, clearly written text with minimal jargon, and block diagrams from you that demonstrate your understanding of the problem and solution. NO CODE.”

As Rensin noted, the first draft will likely contain flaws, so you should ask clarifying questions and debate important decisions until you settle on a reliable technical approach. “This back and forth creating the technical proposal might take hours. Some of my sessions with Gemini have lasted 2–3 days while we debate important decisions. Do not rush this back-and-forth; you will be sorry if you do.” This results in [Exhibit E-I].

Trust but Verify: Constructing Acceptance Criteria

Elephant: Based on the technical proposal in Exhibit E-I, ask the Elephant to write acceptance criteria for each feature using the Gherkin syntax (GIVEN-WHEN-THEN) to create [Exhibit E-J]. Acceptance criteria must not be contingent upon any hard coded, limited set of data.

Goldfish 6: Ask a Goldfish to act as a senior QA lead to review Exhibit E-I and critique the acceptance criteria in Exhibit E-J. Loop this feedback back to the Elephant to create an [updated Exhibit E-J].

Teaching the Elephant

Build a markdown document iteratively to serve as the source of truth for the codebase. Write each of the following sections separately to avoid token limits:

  1. The Elevator Pitch: A brief, plain English description of the problem: 3-5 sentences, just enough that a casual reader can understand what you are trying to do.
  2. The Technical Plan: A jargon-light explanation of the major components and their interactions, include a block diagram. Your goal in this section is explanatory prose and a graphic map of your architecture.
  3. Alternatives: Document the major architectural decisions considered but rejected during Phase 1. You MUST include at least two rejected alternatives per major decision.
  4. Detailed Implementation: Clear the context of your coding agent and have it read the first three sections. Ask it to detail the step-by-step implementation plan, including API contracts, data payloads, database schemas, and data models. This will be the longest section of this document.

The Critic Review and Implementation Readiness

Goldfish 7: Ask the Goldfish to act as an expert technical reviewer and identify missed assumptions, edge cases, unturned stones, or errors in your design document. Update your wiki accordingly and repeat until the critiques are minor.

Goldfish 8: Ask the Goldfish to assume the role of an experienced senior software engineer and assess if the document contains all the necessary information for a successful first-pass implementation. Resolve any questions in the document itself.

Post this polished document, along with your AGENTS.md to your project GitHub wiki as the Project Architecture and Features section. This is the section you will give to your agent to start implementation.

AGENTS.md: to prepare your agent for implementation, adopt part or all of AGENTS.md (rename the file CLAUDE.md if you’re using Claude Code) and ensure that your AI design/coding agent is set up to:

Creating the Story Map

Elephant: Using Exhibit E-I and the updated Exhibit E-J, ask the Elephant to

  1. define the app’s user experience stages,
  2. assign each feature to a stage, and
  3. attach the corresponding acceptance criteria.

Ensure it produces no code nor UI mockups. Later, you will transfer this finalized story map to a Trello board (see What to Submit section below).

Human Considerations and Planning: For each feature, determine whether it should be part of your Skeletal Product, MVP, or Stretch Goals. This is best done by hand because LLM has no concept of effort and time required to do anything. Would each feature be completed in the blink of an eye by an LLM? Or would each feature require hours to days of its own Elephant-Goldfish rounds to implement, followed by hours of human review of the AI-generated code?

Master Competency

During both Skeletal Product and MVP per-team code review, you will be asked to do one or more of the following:

Prior to a code review, you will be asked for a list of code sections each member is responsible for. Every member must have roughly equal portion of the code based assigned to them. A member with no assigned portion automatically gets a ZERO. The responsible member must answer questions pertaining to the code section they are listed with. A second member may be assigned as a backup member. A team member cannot be the backup member of more than one section. If the primary member cannot answer a code review question, including being late to or absent from the code review, the backup member will be given a chance to answer the question, with 25% grade penalty. The grade penalty will be waived only for documented medical or family emergencies.

Your Story Map and your UIUX design, next assignment, together make up your project’s grading rubric. Be sure that you give sufficient thoughts to the features that go into the different stages. Don’t list a whole subsystem (e.g., AR or CV) as a single feature. The smaller the number of features you have, the more your grades will ride on each. In the extreme, if you have only one feature and it’s not working, you will get 0.

Your Story Map MUST focus on the delivery of your core value proposition, not supportive features. For example, even if account setup and a login process are crucial to the security and proper running of your app, do not include them in your Story Map unless the setup and login processes are inextricable parts of your value proposition. Instead, focus on your app’s user experience AFTER the user has signed up and signed in.

During Skeletal Product and MVP grading, if one or more of your planned features turn out to be implementable using the same (or duplicated) code, the features will be merged and counted as one, with corresponding reduction in your total number of features (but no additional grade penalty).

Plan on a good balance between your Skeletal Product and MVP features. Skeletal Product features not completed by the Skeletal Product code drop can be completed by the MVP code drop, but with a 25% grade penalty. Skeletal Product is due in about 6 weeks, MVP by the end of the term.

EXCLUDE from your Story Map all UI features (such as search box, submit button, emoji icon). You will work on those in the next assignment. For example, instead of “create a button to record audio,” you can add a feature to “initialize the AVAudioRecorder/MediaRecorder.” Instead of “create a button to take photo,” you can add a feature to “access the camera.”

INCLUDE in your Story Map, for partial grading of features, the functional, implementation break down of each feature. For example, for feature “search for books,” you can list the following implementation steps:

For feature “facial recognition,” you could break it down as:

The final version of your Story Map, along with your UIUX design, will be a contract listing the deliverables of your project. Once finalized, all listed features “above” your MVP line will be locked and sealed, meaning, any further changes to the listed features would require a re-negotiation of the contract. Also be sure to have features that are Stretch Goals. If you later find certain Skeletal Product or MVP features to be too difficult to implement or irrelevant, you may negotiate to replace them with feature(s) from your Stretch Goals (you can replace a feature, but never remove one without replacement).

What to Submit

There are multiple items due, with submissions on your Trello board and GitHub repo Wiki, NOT on Canvas.

First, create a Trello workspace and board to manage your project. Name your Trello workspace and board with your team name (not your app name, if different). Sample Trello template.

On your Trello board (-5% grade penalty if not to spec):

  1. Your Trello board MUST have these three columns: a. Project Backlog,
    b. Skeletal Product Completed, and
    c. MVP Completed

  2. Your Story Map (60% of “Story map and architecture” grade) posted as the Cover image of the top-most card of your Project Backlog list. Here’s a sample top-most card.

  3. Create a card for each Skeletal Product feature in your Story Map and put it in your Project Backlog list (40% of “Story map and architecture” grade). On each card, provide (a) an acceptance criterion for the feature. ALL Skeletal Product features must have a card with acceptance criteria. List functional implementation steps of each feature for partial-credit project code grading. Each card must also be (b) labeled with Skeletal Product label. In a later assignment, each of your MVP and Stretch Goals feature card must also be labeled accordingly. Each card should also be (c) labeled with the sprint in which you plan to work on it (it’s ok to re-assign cards to different sprints later, as necessary). Your sprint label must specify its start and end dates (time box). You will not get full credit if you don’t use labels, for example if you list the required info in the card description instead of using labels. If you couldn’t figure out how to create labels, please ask teaching staff for help. Finally, tag each card with (d) team member(s) assigned to work on and be responsible for the feature/task. Task assignment on Trello is how custom individual grade will be computed. We want to see a roughly equal distribution of work for the whole project across the whole team, to the best of your ability to estimate the workload of each feature. Members not assigned to any task will get 0 for project grade. Here’s a sample card with: a. Acceptance criterion
    b. Skeletal Product label
    c. Sprint label with sprint number and time box
    d. Assigned member(s)

Next, create a GitHub repository for your team project source code. (Your project repo is separate from and in addition to your tutorials repo.) You will use the GitHub repo Wiki for your project documentation. GitHub Wiki is free to students, but you must sign up for the free GitHub Student Developer Pack. Name your team GitHub repo with your team name. You can make it a private repository for now.

Invite all members of your team and Trello user @eecsreactive to share your Trello board and GitHub repository as Collaborator or Editor, with write access.

Your GitHub repo’s Wiki site MUST comprise the following six parts. Please maintain each part as a separate wiki page on your GitHub repo Wiki site. The Home page of your wiki should be a Table of Contents that lists and links to the following sections:

  1. Getting Started: documentation on how to build and run your project. For now, simply list and provide a link to all 3rd-party tools, libraries, SDKs, and/or APIs your project will rely on directly; that is, you don’t need to list libraries that will be installed automatically as dependencies when installing the libraries you rely on directly. List both front-end and back-end dependencies. Sample Getting Started wiki
  2. LLM Exhibits (20% of Project Documentation grade): Put the following three items from your Scoping exercise here, in one markdown file:
    1. one-page audit table
    2. one-page summary of each Exhibits E-A to E-G and G-A to G-E in chronological order
    3. the full Exhibits E-A to E-G and G-A to G-E in chronological order
  3. Project Architecture and Features (20% of Project Documentation grade): Put the four-part output from the Teaching the Elephant section above here, in one markdown file:
    1. Elevator Pitch
    2. Technical Plan
    3. Alternatives
    4. Detailed Implementation
  4. View UI/UX: leave this wiki blank for now. You will populate it with your UI/UX design in a latter assignment.
  5. Team Roster: a list of team members and each member’s contribution. You may simply list each member’s full name for now, leaving the contribution description to the end of term. Should you want to make your GitHub public at the end of term, what do you want visitors (potential employers) to know about your contribution to this project? Should you ask me for a recommendation letter three years from now, what do you want me to say about your contribution to the project? Sample Team Roster wiki.

  6. AGENTS.md and Honor Code and Peer-Review Pledge: Put your AGENTS.md here. We expect it to contain at least the two stipulations stated in The Critic Review and Implementation Readiness section above. Include in this file, the Honor Code and Peer-Review Pledge, signed by all members of the team:

    Honor Code and Peer-Review Pledge:
    
We, the undersigned, [ HAVE / HAVE NOT ] received aid from one or more 
LLMs or automated coding assistants on this submitted work. If we 
received aid, the specific tools used were (specify models and versions):
[____________________]. Regardless of assistance, we fully understand 
and can defend all code and design choices within this submission. We 
further stipulate that we have peer reviewed every file in the submitted
project code base and confirm that every team member understands the 
execution paths of their assigned modules. We have not concealed any 
violations of the Honor Code.
    
Signed: _________________________  Date: ___________________
Signed: _________________________  Date: ___________________
Signed: _________________________  Date: ___________________
Signed: _________________________  Date: ___________________
Signed: _________________________  Date: ___________________

References

Both the Trello board cards and the GitHub repo Wiki use Markdown to do simple formatting. If you’re new to Markdown, you may find the following useful:

Prepared by Sugih Jamin Last updated: October 1st, 2026

Acknowledgments: I have used Gemini 3.1 Pro and 3.6+ to prepare this document. All structural concepts, technical details, and final editorial decisions remain entirely my responsibility.