A team project in three sprints

• You will work in a team of four or five students. Teams are formed by random allocation within each section, and a sixth member needs justification and approval.
• Your project will be deployed to the cloud and will use a CI/CD pipeline. We will look at your version control history for structured contribution: branching, merging, and meaningful commit messages.
• Your team tracks its work in OpenProject, produces wireframes and mockups in Figma or Frame0, and draws its models in StarUML.
• At each review you present to a panel of faculty and teaching assistants, who act as your product owner and stakeholders. You defend your design and architecture decisions as claims, and we talk through the trade offs and the alternatives.
• Between sprints we introduce changes, as a client would. Your team reconciles each change with its existing design, priorities, and constraints.
• At every review, each of you answers individual questions on the work attributed to you.

Sprint 1 runs in two stretches, with a pause for the winter break and the midterm week. It has 26 active days, within the limit of 30. Burndown and velocity are plotted against active days only, on an axis from 0 to 26. Days shown in gray are Sundays and holidays inside the two stretches.

At each review your team presents to a panel of faculty and teaching assistants who act as product owner and stakeholders. We score the individual lines of the rubric from your own answers and your repository record, and the group lines for the team. Your group marks may be adjusted when your individual record shows a substantially different contribution.

The User Story Board is the product plan that the team builds together and presents to the whole class at Review 0. It is the baseline from which the Sprint 1 and Sprint 2 backlogs are drawn, and Review 1 and Review 2 measure progress against it. It is kept in the team's OpenProject workspace, and the repository is linked to it. The board contains the following.

• The problem statement, the users (personas), and the product goal.
• Epics, decomposed into user stories written in the form of role, goal, and reason.
• Acceptance criteria for every story, written as conditions that can be tested, and a team Definition of Done that states the unit testing expectation.
• A story map along the user journey, with a priority and a story point estimate for each story and the reason for the order.
• Release slices: the stories planned for Sprint 1 (the first working build of about 40%) and for Sprint 2, with dependencies and the main risks to the plan.

Every team member presents part of the board and answers questions on any part of it. If the board changes after Review 0, record the change in OpenProject with a reason, and we will talk about it at Review 1 and Review 2.