Capstone Expansion Expectations

Back to Capstone Expansion Overview

In this section we will cover expectations for the whole project as well as expectations for the Front End team, Backend Team, and the Project Managers.

General Expectations

This project will typically consist of a front-end (FE) and back-end (BE). You should plan to build off your original capstone project repository (or the existing project of the team you’re joining, if applicable). This also means you should continue to meet the following expectations set in part 1:

• One Github Organization to house the repositories, project board, wiki, etc.
• One Github Project Board to track stories and progress
• The FE and BE applications live in separate repositories that communicate with each other using API requests
• Use of continuous integration
• Early and consistent deployment to production
• In-depth README.md for each repository describing the project, setup procedure, testing procedure, screenshots, API documentation
• Create and use pull request templates that document and create discussion for finished features
• Stretch technologies implemented on both FE and BE

If you do not see your project following this outline, then speak to your instructors about it.

Testing

As always testing is expected.

• For projects using RSpec or Cypress, then we expect above 80% test coverage
• If you experiment with new languages or testing frameworks, then test coverage is expected to be at least 25%

Choosing Stretch Goals

The Capstone Expansion Project is about more than just adding more features. We want to be able to demonstrate smart iteration and improvements in our projects while honing our learning processes when approaching brand new topics for the first time. This might include things like:

• Improved UI/Usability
  • Light/dark mode
  • PWA
  • Native mobile app
  • Responsiveness
  • Dynamic updates
• Accessibility
• Observability (how is your app performing?)
  • Performance Improvement
  • Load Testing
• Reliability (if a service goes down, what happens to the rest of my app?)
• Iterating on existing features to make them better
  • This is a broad topic but might include things like:
    • Sending email or text notifications
    • Improved user interactions
    • Automations

Every project is different, and each person has their own learning goals. Please consult with your Instructor PM to choose the right stretch for you and your project.

Project Planning Deliverables

By the end of the first day of the project, your PM will send you instructions in Slack for an Async Check-In. We will be looking for your approximate plan and goal(s) for capstone over the two week project period. The goals can be documented on your Github project board if you have it ready to go or other project planning tool (like Miro) if you’re still working out the details. Please ensure your PM has access to the tools you are using for this project.

We recommend you start small so you can factor in time during the week for your Professional Development work such as: networking efforts, applications, and the Case Study Project.

Check-Ins and Demos

Instructors will serve as project managers and hold check-ins. Each check in on the calendar will have specific instructions for what teams should be prepared to present. Here is a list of some of things you will need to do during check ins:

• Project Planning deliverables outlined in the previous section (first project checkin only)
• Demo the Application
• Project board, what is in progress and if the team is expecting to meet deadlines
• Difficulties, roadblocks, and bugs
• Stories on board for what the next phase will be and what the team is committing to by next check-in
• Review of git commits and PRs

Group Communication Expectations

Communication expectations carry over from Capstone Part 1. They are documented here as a refresher.

Re-DTR

• Review your DTR and update as needed
• If you have a new team member joining the group, please take time to DTR together and get everyone acquainted

Daily Standups

• During standups, reference your project board to make sure it reflects what each developer is working on.
  • You may continue to use the same document as Part 1 for logging standups.
• Refer to Capstone part 1 documentation if you need a refresher on how Standups should work.

Pull Requests

• Review your PR template to ensure it is covering all the information you would like in a PR
• PRs should not be merged until reviewed by at least one other person
• PRs should contain discussions and include multiple people. This might mean pulling in folks working on features unrelated to what you are working on

Project Board

• Should include MVP user stories, chores, bugs, and spikes
• Should be kept up-to-date and members should assign themselves when working on a card.
• The team should look at the planning board at every stand up to make sure it’s up to date.
• Only one project board used by all team members

Retro and Backlog Refinement

• Weekly retros and backlog refinement is scheduled on the calendar.
• Backlog Refinement:
  1. Review Project board and update cards as necessary
  2. Prioritize cards and ensure everyone is up-to-date
• Retro:
  1. As a team, choose a format and follow guide.
  2. Give Feedback to team members.
  3. Capture summary with screenshot of retro board and include in Slack channel with summary of team’s takeaways. Tag project manager.

Conflict Management

• Despite our best intentions, conflicts some times arise among team members
• Conflicts can often be resolved between team mates
  • Retros are a great opportunity to provide feedback and discuss challenges
• After doing your best to resolve the issue within your team, if you are still having difficulties please reach out to your project managers