Frontend Development Objectives
Classroom FE Development Review and Project Start
This lesson starts a Frontend Development review using last year’s nonprofit project work. Teams will review prior examples, choose one project direction, and begin a focused FE plan they can build and revise over the next two weeks.
I will use a sample project from last year as a live model and update it as we go. I will share my progress so students can see how planning, issue writing, and implementation evolve during the sprint.
- Start with review and ideation using the sample storyboard: plagiarism mockup/ideation
- Review the sample mockup vision, similar to nonprofit progress you will inherit: plagiarism prevention mockup
- Choose your team project direction from last year’s reviewed and selected nonprofit work, then begin your Big Issue/Sub Issues plan
Team Kickoff (Big Issue, Sub Issues, Kanban)
Use this as your team starter checklist. Keep writing short and concrete.
Checklist 1: Team Setup (3 Roles)
- Scrum Master/Developer chosen
- Technologist/Developer #1 chosen
- Technologist/Developer #2 chosen
- One project selected from last year’s nonprofit reviews
- Shared board/repo link created
- Team rule set: every task has one owner
Checklist 2: Big Issue (Create One Main Ticket)
- Big Issue title written in plain language
- Nonprofit and user group identified
- Problem statement completed: Users need __ because __
- Success statement completed: We know this works when ___
- Out-of-scope line added: This project will not include ___
- All three team members approve the Big Issue
Checklist 3: Sub Issues (Break Big Issue into Work)
- 3 to 6 Sub Issues created
- Each Sub Issue starts with a verb: Create, Design, Build, Test, Deploy
- Each Sub Issue has one clear deliverable
- Each Sub Issue has one owner
- Each Sub Issue has a done condition
- At least one Sub Issue is for test/demo readiness
Checklist 4: Kanban Starter (Simple Board)
- Board has exactly three columns: To Do, Doing, Done
- All Sub Issues are added to To Do
- WIP rule set: each person can have only one card in Doing
- Pull rule set: move a new card only after current card is done
- Blocked cards are labeled Blocked with reason
- Daily board check: each person updates or comments on their card
Build History (What To Capture In Personal Portfolio Repo)
Collaboration History Checklist
- Add one section named
Collaboration Historyin your Team Portfolio repo - List your team role for this project (Scrum Master/Developer or Technologist/Developer)
- Link one board view or issue set that shows Big Issue and Sub Issues
- Link one artifact for each phase: idea, prototype, implementation, test/demo
- Add one example of a blocked task and how your team resolved it
Program Function and Purpose Checklist
- Add one section named
Function and Purposein your Portfolio repo - Write one sentence: who the user is and what problem is solved
- List 3 key user actions and expected outputs
- Identify one algorithmic or logic-based feature you contributed
- Link to code that proves the feature works
- Add one test/demo note that confirms expected behavior
Final Portfolio Push Checklist
- Commit your history updates with a clear message
- Push to your Portfolio repo
- Verify links open and evidence is readable