Sprint 0 Expectations

The goals of this Sprint are to:

1. To produce a high-level design document for your feature.

2. For all members to have their development environment setup and to establish your staging (“production”) infrastructure and begin deploying code to it (instructions for “production” coming soon).

3. To gain practice with project management and planning out technical work.

1. The Design Document

Your team will produce a design document for your feature. For now, begin writing this in a shared Google Doc with your team. This document will ultimately be markdown file in the docs directory of your team’s repository.

ChatGPT and/or other generative AI tools are not permissible for use in writing this design document. There are at least 3 of you on the team, but generally 4, so between you all there is more than ample time and English-writing ability to craft this relatively short document. The primary value of this document is the thinking, team communication, and internalization of the problem you are trying to solve more than the resulting document itself. If writing produced by generative tools is detected in your design document submission, your group risks earning a 0% for this Sprint.

The markdown document file should contain well written:

0. Title & Team: Title Your Feature (It can be more creative than the requested CFP Titles) and attribute your team members.

1. Overview: Restate the value and need of the feature in your team’s own words.

2. Key Personas: Describe the key personas your feature serves. What are their needs and goals with your feature?

3. User Stories organized by persona, necessity for a minimum-viable feature, and frequency/importance of use.

4. Wireframes / Mockups: Include mockups of your feature’s user interfaces for the most critical user stories, along with brief descriptions of what is going on. These should be made using Figma and the Material UI controls as shown in class.

5. Technical Implementation Opportunities and Planning

   1. What specific areas of the existing code base will you directly depend upon, extend, or integrate with?
   2. What planned page components and widgets do you anticipate needing in your feature’s frontend?
   3. What additional models, or changes to existing models, do you foresee needing (if any)?
   4. Considering your most-frequently used and critical user stories, what API / Routes do you foresee modifying or needing to add?
   5. What concerns exist for security and privacy of data? Should the capabilities you are implementing be specific to only certain users or roles? (For example: When Sally Student makes a reservation, only Sally Student or Amy Ambassador should be able to cancel the reservation. Another student, such as Sam Student, should not be able to cancel Sally’s reservation.)

2. Establish Development Environments

We will distribute instructions for establishing a development environment soon. For now, focus on your design document.

3. Practice project management best practices

Once team repositories are setup (soon!), you will be able to start establishing a project board. For now, focus on your design document and skip over this section.

Team tasks that are delegated out should be added to your final project board(s), given meaningful descriptions or subtasks, assigned to appropriate team member(s), and updated as progress is made. All cards on the project should also be linked to issues in your team repository. This practice is a slight deviation from industry, where non-codebase related project management and tasking may occur in another tool, but for simplicity purposes we will keep all project management concerns in GitHub to gain comfort with the tool and for standardization in the class.

Changes to the codebase, as described in the design document expectation, should be made on branches and pushed to branches before being Pull Requested and Code Reviewed by a team member. This will simultaneously slow down progress and increase your team feature’s quality and increase shared understanding of the codebase which is a worthwhile trade-off in software engineering.

4. Establishing CloudApps Deployment

Instructions for OKD deployment of final projects coming soon.