Project: Sprint 2 Deliverables

Final Due Date: 2024-11-19 11:59PM

Github Classroom
Submission: See detailed submission instructions below.

Sprint Planning Meeting

Each sprint will start with a planning meeting where you the answer the following questions:

• What is the goal of this sprint, i.e. what backlog items can be delivered in this sprint?
• How will you complete the work to implement your sprint goal(s)?

Setting the Sprint Goal

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 out how you will implement the items you have chosen for your Sprint Goal.

I encourage you to not ignore the server 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.

How Will You Implement the Sprint Goal?

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.

Sprint 2 Completion Checklist

At the end of each sprint your team should complete the following tasks:

1. A tagged commit on main (one of “sprint1”, “sprint2”, or “sprint3”) pushed to GitHub marking the completion of the sprint.
2. A set of closed User Stories or other work items in your sprint backlog tracker assigned to that sprint iteration.
3. Working deployment of the tagged commit demonstrating the completed User Stories.
4. The GitHub Actions CI build for your tagged commit is passing.
5. Each team member has completed the confidential self- and peer-evaluation survey (due 24 hours after the Sprint Retrospective).
6. A short in-class demo showing the features that you completed in that sprint.

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).

Sprint Retrospective

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.