Capstone Project

Capstone Project

Learning Goals

  • Students use an agile process to turn acceptance requirements into deployed software (mastery)
  • Students estimate complexity of user stories (functional)
  • Students translate acceptance requirements into user stories that are ready to be worked on (mastery)
  • Students verify acceptance requirements using automated testing (mastery)
  • Students document intent and usage of their code for effective collaboration (functional)
  • Students use pull requests to document discussion about features (functional)
  • Students divide applications into components and domains of responsibilities to facilitate multi-developer teams (functional)
  • Students build applications that execute in development, test, CI and production environments (functional)
  • Students apply accessibility best practices when building their applications (functional)
  • Students explore and implement new concepts learned in class this module or on their own (mastery)


The Capstone Project will last two weeks and will consist of student’s building meaningful, publishable work of their choosing. An instructor will be assigned to each student and act as the Technical Lead.

The project consists of two “sprints”: the first finishes on Friday of Week 4, the other on Monday of Week 6.

Technical Expectations

We would like to give you a fair amount of freedom on this project. We want you to bulid something that you’re excited about, and that you’re proud of. These are a few requirements you should consider when pitching and building your project:

  • You build something usable. You should be comfortable publishing your project by the time it’s due in week 6. A spike or exploration into a new concept without a clear deliverable won’t be accepted.
  • You must apply at least four new techniques, or build your project in a new language and/or framework. New is something from the 4th module (OOJS, Security, Environments, React), or something extra-curricular (something not taught in the Turing backend engineering program).
  • Since accessibility is already in the rubric, it doesn’t count as a new topic, but is required.
  • If you use something cool for your documentation (swagger, JSON-API, etc), we will accept it.

Structure of each week

Each student will submit a project proposal after the “soft launch” here by Tuesday, September 5th at 9 AM. Technical Lead’s will give feedback on the scope of the project either via Github, Slack message, or in person by the end of the day.

Each student will be responsible for setting priorities for their project and communicating those to their Technical Lead. Throughout the week, each student should be tagging their Technical Lead in PR’s if they have questions or want feedback on any code they’ve written.

During the halfway checkpoint:

  • Each student will spend 2 minutes demoing their project to the entire class.
  • Each student will self-assess on the rubric below.
  • Each student has the option to meet with their Technical Lead who will evaluate their progress via the rubric below.

During the project:

  • The student is responsible for communicating to the Technical Lead throughout each sprint if they are not going at a pace to finish what they’ve prioritized.
  • The student is responsible for reaching out to their Technical Lead and the community for feedback/assistance on their code.

At the end of the project (week 6):

  • Students will demo their project to the entire class.
  • Students will be evaluated (in-person with their Technical Lead) on the rubric below.


1. Project Planning & Management

  • 4: Developer has a highly detailed iteration map, sophisticated organization in their tracker tool, and exceptional Git workflow
  • 3: Developer uses an iteration map to plan project scope, breaks down broad features into granular tasks, and exercises good Git workflow (e.g., feature branches, descriptive commits, incremental PRs)
  • 2: Developer has a mental vision for the project iterations, shows some use of a tracker tool, and uses Git effectively
  • 1: Developer shows little evidence of project planning and management

2. Completion & Pace

  • 4: Developer delivers stories committed to before starting the sprint
  • 3: Developer plans stories ahead of sprint and makes some scope adjustments along the way
  • 2: Developer implements very little of the planned sprint
  • 1: Developer does not plan or complete sprint

3. Implementation Quality

  • 4: Project demonstrates exceptionally well tested (where applicable) and maintainable code
    • for topics outside of BE curriculum, developer can speak to best practices applied
  • 3: Project exhibits tested (where applicable), maintainable, and well-organized code. Developer can speak to architecture and implementation decisions
  • 2: Project demonstrates some gaps in code quality and/or developers cannot defend their decisions
  • 1: Project demonstrates poor factoring and/or understanding of general programming principles such as MVC and OOP

4. Application of Techniques

  • 4: Developer builds project in a new language(s) or framework(s)
  • 3: Developer implements four new techniques or patterns
  • 2: Developer implements 3 or less major techniques that have not been previously attempted
  • 1: Developer does not implement new techniques

5. Documentation

  • 4: Developer also adds a screencast, tutorial or other wow factor
  • 3: Developer provides easy to navigate documentation showing how to setup and contribute to the application
  • 2: Developer provides barebones documentation showing how to get the dev environment up and running
  • 1: Developer provides insufficient documentation

6. Accessibility

  • 4: Developer expertly implements features to follow accessibility best practices
  • 3: Developer implements code to increase accessibility
  • 2: Developer considers accessibility issues but has not yet produced code to address them
  • 1: Developer does not consider accessibility issues