CompSci 308
Spring 2024
Advanced Software Design and Implementation

Lab Team Meeting: Sprint Planning

In your OOGASalad teams, take some time to prioritize, organize, clarify, and assign the project's features that will be done this Sprint.

In industry, Sprints often end with a demo to stakeholders, and progress is measured by how many features (i.e., things a customer would see as a reason for buying your product) were completed in the Sprint, rather than how much of the data structure was set up (or some other "technical" goal). It is each person's responsibility to ensure the implementations of those features are well-designed and tested. As a result, you need to allot enough time to not only implement, but design and test each feature when planning your sprint.

The result of a Sprint should be running code that is demonstrably improved over the last Sprint (ideally well tested and robust against crashing).

In this exercise, your team will:

  1. Starting a New Sprint
  2. Plan Collaboratively
  3. Document the Plan
  4. During the Sprint

Resources (Reminder)

This series of short blog posts describes how to think about building software differently using GIT, in general, and Gitlab, specifically, to support managing your project:

The quick summary is:

Starting a New Sprint

Groom your Backlog by considering the following:

The result of this planning should be updated Issues in Gitlab.

Plan Collaboratively

Refine your goals so that they can be reasonably estimated and turned into Gitlab Issues:

The result of this planning should be further updated Issues in Gitlab.

Document the Plan

Estimating the complexity of your Backlog Issues can be challenging so try making them as small as possible by breaking big issues down into several smaller issues (since most programmers start with issues that are too big). For each Backlog Issue planned for this Sprint, break it down further such that it is:

The result of this planning should be a Milestone in Gitlab, populated with updated Issues, that accurately reflect each team member's velocity (independent of pressure from the team or others in class).

During the Sprint

By breaking Backlog Issues down to this level of detail your team (and other stake holders) will see the following benefits during the Sprint:

This is only effective if you update your progress regularly by changing an Issue's status online through Gitlab's Issue Board or using keywords in your GIT commit messages.

Submitting your Work

Update your Gitlab project to reflect the new and updated Issues made during the Planning steps.