About Capstone

Course Structure

All courses follow a similar structure!

The first week is dedicated to project or group selection, which is probably why you're here! These projects are the focal point of the course and aim to give you the experience of working on a real-life project.

Once you know what project you're in, teams will complete seven sprints that act as development chunks over an approximately 14-week span. During these sprints, you, your product owner, and fellow team members discuss what work needs to be done and how to achieve it! Make sure to create development artifacts during this stage, as that will make your life much easier for the final leg of the journey.

The final sprint is treated differently from the rest and focuses on the final deliverables, posters, and presentation. Instead of development, the team creates any remaining artifacts and prepares to show their project to the judges. It's okay if you didn't make a finished product since the goal is to gain experience from the process. Besides, that means the project could be picked up by another group of students who could continue your work next semester!

Project Selection

Selecting a project is pretty straightforward. All you have to do is submit your course's respective form and order projects by interest. Once that's done, the algorithm handles the rest! After about a day, you'll receive an email stating your project placement. The algorithm does its best to place you and everyone else in a project they'll be happy with, but you may not always get your first preference due to availability.

Meetings

Team meetings are a mandatory part of these courses that help maintain communication between team members and product owners. For all meeting submissions, it is best practice to note the start and end times of every meeting and who attended.

Daily Scrum

Daily Scrum Meeting Minutes Template

Duration: 10-15 minutes

Frequency: 5 days per week (10 days per sprint)

These are meetups with your teammates to update each other on everyone's progress, plans, and hurdles. Unlike other meetings, the document storing daily information should not be reset. Instead, it is best to add a new document page for every additional daily such that submissions contain the current and all past daily meetings.

Sprint Planning

Sprint Planning Meeting Minutes Template

Duration: 30-45 minutes

Frequency: Every 2 weeks (start of each sprint)

At the beginning of each sprint, the team meets with the product owner to decide on new goals. These goals are user stories and can be created on the day of the meeting or carried over from past sprints. When choosing user stories, members should consider how much time they have to work on their user stories over two weeks, whether they should split the story into smaller pieces, and if they should share the work with another team member. Everyone should have at least one user story, preferably more, assigned to them. The workload should be balanced between all members. Once all created user stories are allocated, the team's velocity is estimated to be the total number of user stories.

Sprint Backlog Grooming

Sprint Backlog Grooming Meeting Minutes Template

Duration: 30-45 minutes

Frequency: Every 2 weeks (middle of each sprint)

The team asks the product owner any questions that arose over the first week of the sprint and discuss modifications to existing user stories. If needed, new user stories can also be made. If a user story is taking longer than expected to complete, consider pushing that user story into the following sprint.

Sprint Review

Sprint Review Meeting Minutes Template

Duration: 30-45 minutes

Frequency: Every 2 weeks (end of each sprint)

Once the end of a sprint has been reached, the team meets with the product owner and reports their progress to them. The product owner approves or rejects each completed user story, and these decisions are logged. Any declined or backlogged user stories are marked for continuation into the next sprint.

Sprint Retrospective

Sprint Retrospective Meeting Minutes Template

Duration: 30-45 minutes

Frequency: Every 2 weeks (after each review)

This meeting is designed to help improve the team's efficiency after each sprint. Address whether members are working as scheduled and accurately estimate the team's velocity and time required for a user story. The team then brainstorms ideas to resolve these issues through changes in the process or product. It is equally important to identify good practices to continue.

Posters

Poster Templates

All Capstone I students in a team will get to share a single poster, while the remaining team members need one per person. This is also the first thing your fellow students and judges will see on presentation day, so this would be the perfect place to emphasize significant parts of your work! The structure necessary for the posters themselves is relatively flexible. However, don't forget to credit those who helped you throughout the semester, like your product owner. Include any diagrams or other details that would be useful to understand your project at a glance.

Final Deliverable

The final deliverable is your last submission for the course and acts as a summary of all the progress your team has made on the project! Complete this before presentation day so judges can review your deliverable. While this may seem intimidating, the task becomes much easier if the work is started early on and completed throughout the semester.

Note: Posters are also included in the deliverable zip file submission.

Project Documentation

Project Documentation Template

This is the bulkiest part of the final deliverable and covers a wide range of information.

Abstract & Introduction

Introduce your project to the judges and future developers. You should describe the original version of the project, if applicable, and briefly discuss its flaws. Make sure to talk about your new system as well.

User Stories

Provide details about implemented user stories or planned for implementation in this project iteration.

Project Plan

Discuss the planning that went into this project through agile development techniques. In addition, any components that were utilized for this project are also described here.

System Design

Describe all design decisions that went into this project. The architectural patterns are outlined and explained, and the entire system is shown in a package diagram. The subsystems and design patterns are also defined in detail.

System Validation

Detail your steps to validate each portion of the project by ensuring that it fulfills its purpose and functionality as described by the product owner. Any data collected while validating should also be logged here.

Glossary

Define any words used in the rest of the document that the judges or future developers may not recognize. If you're unsure which words should or shouldn't be defined, get a non-STEM friend and see what words explode their brain (probably everything). When in doubt, define the term.

Appendix

Any artifacts that weren't covered in the previous section should be added here. This includes but is not limited to any remaining UML diagrams, user interface examples, and sprint review reports.

Presentation

Senior Project Presentation Template

Despite the fact you won't be presenting this to anyone in person, the presentation has a few uses. When the judges review your project on presentation day, this will be one of the first things they look at. This is also essential for making the introductory video for your project. And, of course, this is a mandatory part of your final deliverable.

Each slide is relatively self-explanatory and listed below:

Title Slide
Problem Definition: What the project used to be and what it is now.
Use Cases: The most notable use case.
User Stories: A list of every completed user story from this semester.
Sequence Diagram: The most notable sequence diagram.
Architecture: Any architectural patterns and a package diagram.
Deployment Diagram
Safety & Persistence: A list of security or privacy features and how the project maintains data persistence.
Class Diagram
State Diagram (optional)
Main Algorithm: The most notable algorithm's pseudocode.
Test Suites & Cases: A description of each test case and test suite and a quick mention of any automation scripts in the process.
Summary

Code

There will need to be a code folder containing a README.txt and any project source code, including executables and website files. The readme explains the directory structure for the folder. Include any manuals, installation guides, or maintenance instructions in this folder.

Videos

Given that these videos use resources from the final deliverable, recording these should be left for last. The required content of each video is not strictly defined, so it is somewhat left to interpretation based on the title.

There are a total of 4 videos to be completed for the final deliverable:

Introductory Video: Utilize the presentation to give a general introduction to the project and show progress.
Maintenance Guide: Covers any required maintenance and how to access back-end parts of the project for maintenance purposes.
Shortcomings/Wishlist: Shows any hurdles that couldn't be overcome or anything that the team would've liked to add if they had more time.
User Guide: For each type of user the project may have, the video should show how to use the final product.

Page updated

Google Sites

Report abuse