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 students meaningful, publishable work of their choosing. An instructor will be assigned to each student and act as the Technical Lead.

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 two new techniques. New is something from the 4th module (OOJS, Security, Environments, React), or something extra-curricular. Something not taught in the Turing Back-end 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), I would count that.

Structure of each week

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

At the beginning of week one and during the checkpoint, each student will set their sprint (aka what they want to accomplish that week). 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 will meet with their Technical Lead who will evaluate their progress via the rubric below.

At the end of the project (week 6):

  • Students will also demo their projects.
  • Students will be evaluated on 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 the set of stories by the end of the sprint.
  • The student is responsible for reaching out to their Technical Lead and the community for feedback/assistance on their code.


1. Project Management

  • 4: Feature and scope related conversations happen within the tracking tool.
  • 3: Student is using well formatted user stories and moving cards through each status in realtime
  • 2: Student has used some tracking tool as a respository of information
  • 1: Student barely uses a tracking tool, or does not use one at all

2. Completion & Pace

  • 4: Student is proactive in understanding scope and is able to commit to stories before starting the sprint
  • 3: Student is able to set and update expectations so that there are no surprises on the last day of the sprint
  • 2: Student does not have agreed upon stories completed at the end of the sprint, but has a plan to get them done
  • 1: Student does not have agreed upon stories completed, and has no plan to complete them

3. Implementation Quality

  • 4: Project demonstrates exceptionally well tested and maintainable code.
  • 3: Project exhibits tested, maintainable, well divided code. Developers are able to 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 MVC.

4. Application of Techniques

  • 4: Project has implemented four or more major techniques that were new to the student.
  • 3: Project has implemented two major technique that were new.
  • 2: Project has a implementation in progress of one major technique that has not been previously attempted.
  • 1: Project does not implement new techniques.

5. Documentation

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

6. Accessibility

  • 4: Project has expertly implemented features to follow accessibility best practices.
  • 3: Project has implemented code to increase accessibility.
  • 2: Project has considered accessibility issues but has not yet produced code to address them.
  • 1: Project has not considered accessibility issues.