| Date | Sprint | Group Deliverable | Individual Deliverable |
|---|---|---|---|
| 3/29 | 0 | Project setup checklist and initial design | Working individual development setup |
| 4/15 | 1 | Sprint 1+ checklist | Sprint evaluation survey |
| 4/29 | 2 | Sprint 1+ checklist | Sprint evaluation survey |
| TBD | 3 | Final checklist and group report | Individual project report |
Please read through the entire set of Getting Started instructions first, before performing any of the steps! Follow the instructions very closely, the setup is different from how we handle individual assignments.
Click through the GitHub Classroom link.
Unlike past assignments, this is a “Group” assignment in GitHub classroom. When you click through you will be presented with the option to join an existing team or create a new one (unfortunately we can’t initialize the teams automatically). Select your team if it already exists, or if not, please create it. Please use the names (VT mountains) I specified if you are creating a team. Note that these names are just for organizational purposes, they do not have anything to do with what you ultimately choose to call your application.
Everyone needs to click through! Doing so will add you to the corresponding GitHub team, giving you access to your team’s repository. Changing GitHub classroom teams seems to be an open issue, so please be careful at this step.
Review the Scrum Guide, and the different roles, meetings and artifacts that make up the Scrum process.
Start thinking through (and discussing with your team if possible) your application’s major features. I suggest arriving at the Sprint 0 planning meeting with an idea of the “epic” User Stories for your application. Review the User Stories included in the proposal for your project (and others).
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.
As an individual complete the getting started tasks listed above under “Getting Started”.
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.
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). Check out this minimal example for the “in-class” application. 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. The key fields you need are “status” (to indicate if the item is an “epic”, in the product backlog, sprint backlog, or done), the size (one of 1, 2, 4, or 8) and the associated sprint. Priority can be indicated by the relative position in the board column (you can drag up items up and down). Note you will need to tweak the default setup for the GitHub project (e.g., to set the sprint dates). You are welcome and encouraged to add additional fields if that is helpful to your team.
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 what to do (sketch of the intended UI, preliminary data model, etc.). You can drag pictures into your backlog items and more (they are not just titles).
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.
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. 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.
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.
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.
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.
package.json file(s) with the project name, a project description, contributors, repository, etc.💻 pnpm test and 💻 pnpm run lint execute without error for all project components, even if there are no actual tests.💻 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”.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..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).README.md has been updated with the following:
💻 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.The instructor(s) will provide feedback on your initial design approach as you start Sprint 1 to help your team get headed in a good direction.
As an individual make sure you that you can successfully run the project in your development environment.
Each sprint will start with a planning meeting where you the answer the following questions:
Choose a subset of your highest priority items from the Product Backlog as your Sprint Goal. The Sprint Goal (or Sprint Backlog) is the set of functionality that you will implement during the Sprint. Accurately scoping the Sprint Goal depends on knowing how much work each story will require and your team’s capability (velocity). Both will be difficult to estimate at first. Thus be prepared to adjust your Sprint Backlog as you begin to determine ow you will implement the items you have chosen for your Sprint Goal.
I encourage you to not ignore the server-side functionality in your early work, although you may find it easier to get started by implementing only a minimal memory-backed server (recall from the practical that you can build a very useful server using in-memory data structures instead of a database). I would suggest postponing “necessary evils”, such as CSS and user authentication (not the User model, just the authentication) that we will discuss later in the semester, to subsequent Sprints.
Begin designing the features you selected for your Sprint Goal. As you do so, aim to break complex User Stories down to smaller User Stories (on the order of a single day’s coding effort) and their corresponding Scenarios. Your goal is to be able estimate the Story Points for each item in the Sprint Backlog. Each item, and its corresponding point value, should be entered into your team’s backlog tracking tool.
As you refine the User Stories, begin to create or update existing CRC cards for the nouns in the stories. Using your lo-fi storyboards, break your Views into React components. As you refine the design for each item, update the tracker with the additional information (e.g. attach pictures of the storyboards, CRC cards, etc.). Each item in the backlog should have all the information need for development.
As you get deeper into the design process, you will likely find it helpful to begin to take ownership of different stories and split into smaller sub-groups to work on those specific items.
At the end of the meeting, you should have defined your Sprint Goal and have an initial design for those features of your application. Each team member should have taken responsibility for one or more items from the backlog.
At the end of each sprint your team should complete the following tasks:
The demo is a short (no more than 4 minutes) presentation demonstrating the just-completed features of your application. There are no slides, instead you will demonstrate your software live while describing the relevant user stories. The goal is to elicit feedback from your classmates and or customer (if relevant). The demonstration should run from your deployed application not a local development setup. Since the demo is so short, only 2-3 team members need to present (but it does need to be a different set of team members for each sprint).
Immediately after the demonstrations, each team will conduct a Sprint Retrospective. The Retrospective is “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” Ask yourself what aspects of your development process and tools worked well and which could be improved (those need not be mutually exclusive lists). At the conclusion of the Retrospective your team should have identified improvements that you will implement in the next Sprint. Make sure to keep a record of your discussion and any improvements you plan to make. The outcomes of your Sprint Retrospectives will be part of final project report.
There is no one way to conduct your retrospectives, but an effective retrospective process has the following features:
The checklist for the end of the project is largely a superset of the “Sprint 1+” deliverables.
The final checkpoint is intended to ensure that your project could be “handed off” to a future team for enhancements and maintenance, that is a future CS312 group could get your application “up and running” in both a development and production environment without your help.
Make sure the following is true for your application on the main branch when starting from a fresh clone of your repository:
💻 pnpm install.💻 pnpm run dev in the top-level directory successfully starts the application in the development environment. If any additional steps are needed to the run the application in development (e.g. starting a database, migrating and seeding the database, etc.) document those steps (including any commands) in your README.md file.All tests and linting pass, i.e. the following commands do not give errors (should be true if your CI build passing):
💻 pnpm test
💻 pnpm run lint
.env.local, to the instructor(s) (don’t include those secrets in your README). For example, “the ‘AwesomeApp’ requires a Google Maps API key and a Google authentication client ID”. Any other information needed to use the application in production, such as an “admin” password, should be similarly documented.In short, using just the information in your README.md file and any “dot-env” files you send to the instructor(s), we should be able to successfully develop and deploy your application starting from a fresh clone of your repository.
At the end of the semester you will give a 10-15 minute technical presentation about your project. Your presentation should include:
We do not expect that everyone will be present or that everyone will actually be a presenter. However everyone is expected to contribute to creating and refining the presentation. If you are not present make sure that you are equivalently contributing to your team in other ways.
We expect your presentation will have three “main” sections:
As a team, submit a three-page (max) write-up to Gradescope summarizing your project. The report must discuss the following:
In addition to the above, we should be able to see in GitHub the User Stories/work items and estimated difficulty that you assigned to each Sprint Goal (i.e. what you planned to do for that sprint) and which items were completed by the end of the Sprint (i.e. what you accomplished during the sprint). In an Appendix (which does not count towards your page limit), describe how to find the above information in your tracker (i.e. how Sprint goals are tagged, how “done” is indicated, etc.). If the above information is not available in your tracker, please include it in a table in the Appendix.
We expect that there will be substantial overlap between the final presentation and write-up. That is intended. Think of the write-up as the “take home” accompaniment to your presentation.
Only one group member needs to submit your write-up to Gradescope. When they do so, the submitter should add their group members as shown here.
As an individual, submit a TBD-page (max) portfolio document that demonstrates your contributions the project in the rubric categories listed below. Your portfolio should specifically include:
We will jointly define the goals for your specific project as the project begins and evolves. Note that unlike our programming assignments there isn’t a pre-determined goal, but instead you as a team are defining the “face” of your Mona Lisa. Your project is primarily evaluated on your demonstration of effective development processes, not the end result. However, effective development processes lead to deploying working and maintainable code, i.e., a process that doesn’t produce a deployed application is by definition not effective.
Each sprint your team will receive feedback based on the following metrics:
To facilitate tracking contributions when Pair Programming, use GitHub’s co-authoring feature. Add the following line to the end of your commit message (after a blank line):
Co-authored-by: name <name@example.com>
The key information is the e-mail address, which must be the e-mail address associated with the person’s GitHub account. Each commit can have multiple co-authors.
As describe in the syllabus the final course grade will incorporate an evaluation of your individual contributions to the project based on the following rubric.
| Category | Exceeds expectations | Meets expectations |
|---|---|---|
| Technical contributions | High-quality implementations of both frontend and backend components, including tests, for two or more meaningful features | High-quality implementations of both frontend and backend components, including tests, for one meaningful feature |
| Consistent effort | Makes meaningful technical and non-technical contributions in all sprints consistent with time expectations for class | Makes meaningful contributions in 2 of 3 sprints |
| Development practices | (Almost) always employs SW development best practices, e.g., effective use of backlog, VCS, pull requests, etc. | Usually employs development best practices |
| Teamwork | (Almost) always an effective teammate, i.e., productive, cooperative, supportive, positive, self-directed, communicative, reliable. | Usually an effective teammate. |
You are welcome (and encouraged) to use any of the technologies we have worked with in class (and libraries for those technologies, e.g. various React libraries). Outside of those technologies, please check in with the instructor(s).
Yes! The key requirement is that your project is deployed and publicly available (i.e., not just running in development mode on your personal computer). You are welcome to use any platform that meets those requirements. That said only the “official” approach described above will be actively supported.
In past years we have observed a number of anti-patterns:
I encourage you to revisit the “Advice from CS169” slides sprinkled throughout our lectures. Those very relevant suggestions are sourced from undergraduate students in a similar class, implementing very similar projects.