Project: Sprint 0 Deliverables

Final Due Date: 2024-10-18 11:59PM

Github Classroom
Submission: See detailed submission instructions below.

Sprint 0

The focus of Sprint 0 is project setup, planning and design, not coding. At the end of Sprint 0 you should have all of the infrastructure for your team/project setup, an initial set of “epic” User Stories and an initial set of “lo-fi” sketches of your application design.

Before the First Sprint Planning Meeting

As an individual complete the getting started tasks listed above under “Getting Started”.

Agenda for the First Sprint Planning Meeting

You have a lot to accomplish in your first formal meeting, including initializing your repository and other tools so that you can begin development in Sprint 1, defining the initial features of your application, and starting the design process.

Administrative Tasks

Setup a way to communicate as a team

You could use Slack, Discord, group messaging, e-mail, or whatever tool(s) are most effective for you.
Setup your Product Backlog

We will use GitHub project management features to maintain the product backlog and sprint backlog(s). You should create your backlog using this template. It includes the critical fields that you need: sprint (to indicate which sprint the work should be completed in), status (to indicate if the item hasn’t been started, is in progress, or is completed), size (one of 1, 2, 4, or 8), and item type (epic or user story). Priority can be indicated by the relative position in the board column (you can drag up items up and down). You are welcome and encouraged to add additional fields if that is helpful to your team.

Check out this minimal example for the “in-class” application. You’ll note that this uses a slightly different structure than our template for this semester, but it should give you a sense for what your backlog might look like when you’ve actually added user stories! Each “item” can have text, images, etc. The GitHub “project” is linked to your repository and the items become issues in your GitHub repository that you can also reference in commits, etc.

As is often the case in this course, there are many tools we could use for project management and some of those may be “better” than GitHub. However, we are going to standardize on GitHub to reduce the overall logistical complexity and ensure a consistent workflow across the class. You will be tempted to create shared drives, Google docs, etc. to maintain information about your project. I encourage you to use the backlog and backlog items for that purpose so there is a single, consistent, source of information about the next steps for your project. The backlog can be a very powerful tool for enabling an efficient asynchronous workflow. As you finish one feature/task, you should be able to identify from the backlog that next most important work to be done and from the information included with that backlog item know to do (sketch of the intended UI, preliminary data model, etc.).
Select your Product Owner (if you have an external customer)

If you have an external customer, select a Product Owner for the first sprint. The Product Owner will be the primary interface between the Development Team and Customer. In between group meetings with the customer, the Produce Owner will be the single point-of-contact to ensure efficient and effective communication. If you do not have an external customer that role is not needed. In our implementation of Scrum, the Development Team will play a bigger role in managing the Product Backlog than is described in the Scrum Guide. We won’t need an explicit Scrum Facilitator (Scrum Master), but if your team finds it would benefit from someone taking on that role, I encourage you to do so (but make sure to rotate each sprint). Recall that the Scrum Facilitator is not the leader of the team but instead is responsible for facilitating the Scrum process. The Development team, and only the development team, is responsible for determining how to turn the Product Backlog into working software.

Initial “Epic” User Stories and Storyboards

Recall that agile methods discourage extensive up-front design. But you still need to identify the problems your applications should solve and sketch out the major features. Begin your first meeting by defining and prioritizing some of the “epic” User Stories for your application, i.e., the major features. If you have an external customer, you should be defining these users stories in collaboration with your customer. You should add your epics to github with the “Epics” item type.

Concurrently begin your lo-fi prototyping. Start drawing simple storyboards for how the stakeholders in your User Stories will interact with your application. Discuss these storyboards with your customer.

At the end of this phase of the meeting you should begin to populate your Product Backlog with an initial set of User Stories. While the “epic” User Stories should describe major functionality, you will need to turn those large features into multiple smaller user stories that can be implemented within a single sprint. That is your Product Backlog should be an “expansion” of your epic User Stories into more manageable increments.

Resist the temptation to deeply brainstorm all aspects of your application. Recall the Mona Lisa example and our “Iterative Incremental” approach. Brainstorm “wide but shallow” to define the broader problem your application will solve (e.g. “woman in a pastoral setting”) and how you will generally implement that solution (e.g. the “line” drawing). But initially focus most of your attention, i.e., brainstorm “deeply”, on the core feature(s) of your application (i.e. the face of the Mona Lisa).

Don’t hesitate to create (epic) User Stories for all your ideas. Creating a user story is not a contract, you will modify and prioritize these backlogs as you go. The moment where you commit is when you select a user story from the product backlog for the sprint backlog, i.e., plan to implement that feature in the current sprint.

Defining Nouns, Verbs and Views

As you refine the User Stories, begin to create CRC cards for the nouns and verbs in the stories. Look back through your User Stories. The subject and objects of your User Stories are good candidates to become nouns. The nouns will be become the Models in your application and the verbs will often become routes in your server (Controller) or actions in your React components.

Using your lo-fi prototypes, break your Views into React components. As you refine the design for each item, update the backlog items with the additional information (e.g. attach pictures of the storyboards, CRC cards, etc.). Each item in the backlog should eventually have all the information needed for development.

Team Workflow

You should also take a moment to think about how you want to approach development as a team. Make an initial plan about how much of the work will be done using pair programming, how many sets of eyes need to review pull requests (at least 1), how your team is going to communicate, etc.

Project Setup or “Sprint 0” Deliverables

As a group complete the setup and design checklists below (as a group does not mean that all members need to be physically present, just that all of the steps have been completed for your project). As an individual complete the setup checklist below. Note that you need to complete some group setup tasks first.

Group Checklist for the Project Setup

Your project repository has been created in the class GitHub organization and all team members are part of the GitHub team for your project (created by GitHub classroom). That is everyone has completed the Getting Started instructions.
The GitHub classroom assignment initializes your project with a skeleton. Update the package.json file(s) with the project name, a project description, contributors, repository, etc.
You have setup a “GitHub” project to manage your product backlog and spring backlog. Any team member should be able to go the project page to find the next most important feature (user story) to work on and any designs or other information they need to implement that feature.
All team members can successfully clone the repository and run the project in their development environment.
💻 npm test and 💻 npm run lint execute without error for all project components, even if there are no actual tests.
The project repository is successfully integrated with GitHub Actions for CI, i.e., Github actions tests all components of the project and reports “build: passing”.
The skeleton is deployed to csci312.dev. Any team member who will deploy needs to complete the pre-requisites, only one team member actually needs to deploy. You can read more about deployment in class here.
1. As a prerequisite, all developers should have added an SSH key to GitHub. Doing so is necessary to obtain deploy permissions. Add the deployment repository as a remote in your repository: 💻 git remote add deploy git@csci312.dev:<project name>, e.g., 💻 git remote add deploy git@csci312.dev:simplepedia. Note that <project name> is the mountain name assigned to your group, e.g., “mansfield”.
2. Push the main branch to the deploy repository: 💻 git push deploy main. This should automatically build and deploy your application at https://<project name>.csci312.dev. Any errors should hopefully be reported on in the terminal as the push proceeds.
3. If you (later) need to add entries to the .env.local file, you can do so with 💻 ssh git@csci312.dev secrets <project name> KEY=value, where again <project name> is the name assigned to your group. KEY=value is the value you want to add or update in the file (without any spaces).
The top-level README.md has been updated with the following:
1. A GitHub actions workflow status badge showing build status for the main branch (should be “build: passing”)
2. A brief explanation of the need your application addresses
3. A link to the deployed application
Have integrated at least one Pull Request (for example creating the deployment files and updating the README) in which one teammate creates the PR and another teammate reviews the PR.
A commit tagged “sprint0” pushed to GitHub marking the completion of the project setup, You can tag the last commit as “sprint0” with 💻 git tag sprint0. When you push to GitHub use the --tags option to ensure that your tags are pushed as well, e.g. 💻 git push origin main --tags.

Group Checklist for Sprint 0 Design Review

Populate your GitHub project with your “epic” User Stories, that is the main features your application will implement. These User Stories should be in Connextra format, e.g. “As a [stakeholder], I want to…” and satisfy the INVEST criteria. Begin translating those epic User Stories into more specific manageable user stories in your Product Backlog.
Create a set of lo-fi storyboards for the main views in your application. These storyboards should show what will become the main React components in your application. The storyboards should be attached to the relevant backlog items.
Create CRC cards for main “nouns” in your system. The nouns will be become the Models in your application and the verbs will often become routes in your server (Controller) or actions in your React components. Images or transcriptions of the CRC cards should be attached to backlog items for the server side of your application (not all backlog items will necessarily be User Stories).

The instructor will provide feedback on your initial design approach as you start Sprint 1 to help your team get headed in a good direction.

Individual Checklist for the Project Setup

As an individual make sure you that you can successfully run the project in your development environment.