CHIP 10.5: Agile Iterations (Final Project)
CHIP 10.5, Agile Iterations, is the final project for CS 169A: your team of four will develop a SaaS application over two Agile iterations, practicing everything the course has covered — user stories, BDD/TDD, branches and pull requests, continuous integration, code review, and deployment. The project category is worth 20% of your course grade.
This page is a one-page introduction. The detailed, iteration-by-iteration instructions will be released in a project overview document.
How it works
Your team works out of a shared repository in the course GitHub organization
(cs169/fa26-chips-10.5-XX). The project runs as two iterations, each
following the same Agile ceremony structure:
| Deliverable | Who | What |
|---|---|---|
| A. Planning meeting | Team | Meet, groom the backlog, write/point user stories for the iteration, and submit your plan. |
| B. Code submission | Team | The iteration’s code: feature branches, pull requests, passing CI, deployed app. |
| C. Video + links submission | Team | A short demo video walking through what you shipped, plus links to your repo, tracker, and deployed app. |
| D. Retrospective | Individual | What went well, what didn’t, and what your team will change next iteration. |
| E. Teammate evaluation | Individual | Confidential peer evaluation of each teammate’s contribution. |
Iteration 2 is weighted more heavily than Iteration 1 — teams are expected to improve as they go; the retrospective is not a formality.
Milestones (draft FA26 dates)
| Date | Milestone |
|---|---|
| Wed Oct 28 | CHIP 10.5 released (tentative) |
| Mon Nov 2 | Iteration 0/1 begins — project work starts |
| Wed Nov 4 | Iteration 1 planning meeting |
| Fri Nov 13 | Iteration 1 due — code, demo video, retrospective, peer evals |
| Mon Nov 16 | Iteration 2 begins |
| Fri Nov 20 | Iteration 2 planning meeting |
| Fri Dec 4 | Iteration 2 due — code, demo video, retrospective, peer evals |
Grading
- Team deliverables (planning, code, video) are graded per iteration; your individual score also reflects your commits/PRs and your peer evaluations.
- P/NP students: you need 50% or more on the project (including peer eval scores) to pass — easy to achieve as long as your peers don’t report that you were absent and not contributing.
- The project has no automatic extensions — iterations are scheduled team events, like real sprint boundaries.
Teams
Teams of 4 are formed shortly after the add/drop deadline via the team matching survey (required for everyone, even if you’ve already found teammates). You’ll practice working together on the regular CHIPS before the project starts.
Before you start
Finish Module 10 — Scrum, branches, pull requests, and continuous integration are exactly the skills the project exercises.
AI Use Policy
This assignment follows the course AI Policy, which will be published on this site before it is needed. Until then, the rule from the Syllabus applies: you must be able to explain everything you submit.
Your team may agree on how to use AI tools within the course policy, but every team member is responsible for understanding the code the team ships — code review does not stop being your job because a model wrote the first draft.
Running Code and Tests
Run everything below from the root of your clone. If Ruby isn't installed yet, work through Local Development first.
Install the dependencies
bundle install
Run this once after cloning, and again whenever the Gemfile
changes. Prefix the commands below with bundle exec so you run
the same gem versions the autograder does.
Boot the project
Create the database (once, and after any new migration), then start the Rails server:
bin/rails db:migrate
bin/rails serverThe app is then at http://localhost:3000; Control-C stops the server. To try one thing without clicking through the UI, use the console, which loads your app and its models:
bin/rails consoleRun the tests
Run the RSpec suite the way the Gradescope autograder will — get it green locally before you submit:
bundle exec rspec # the whole suite
bundle exec rspec spec/YOUR_FILE_spec.rb # one spec file
bundle exec rspec spec/YOUR_FILE_spec.rb:42 # one example, by line number
bundle exec rspec --format documentation # every example's descriptionEach failure prints the file and line of the failing example along with what it expected — start there rather than at the top of the output.
Run the Cucumber features
Cucumber runs the .feature files — the acceptance tests that
describe the app's behavior from the user's point of view:
bundle exec cucumber # all features
bundle exec cucumber features/YOUR.feature # one feature file
bundle exec cucumber features/YOUR.feature:12 # one scenario, by line