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:

• Always start with an issue
• The Gitlab Issue Board
• It's all connected in Gitlab
• Use Protected Branches Keep Your Code Safe
• Code Review via Gitlab Merge Requests

The quick summary is:

• create Issues before you do the work, including assigning them to a Milestone (Sprint)
• move and tag those issues on Gitlab's Issue Board
• close or update issues with your commits or Merge Requests
• label your commits as to their purpose

Starting a New Sprint

Groom your Backlog by considering the following:

• remove Backlog Issues that are no longer appear relevant
• develop existing Backlog Issues to ensure they have sufficient detail or updated information
• create new Backlog Issues in response to newly discovered needs or goals
• reassess the relative priority of all Backlog Issues
• correct existing estimates of high priority Backlog Issues in light of newly discovered information

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:

• discuss each person's honest capacity for this Sprint based on your outside of class activities (midterms, interviews, illness, etc.)
• determine the team's priorities for what needs to get done during this Sprint
• use those priorities to identify a set of Backlog Issues that need to be completed (for this step just try to list as many as possible)
• collect the Backlog Issues into categories that clearly complete end-to-end features (so that a little bit of all "levels" are represented)
• for each category, estimate its complexity (e.g., using Planning Poker to reach collective agreement) including how you will know it is done
• look at the estimated categories of Backlog Issues and compare it to the limit you think can achieve in this Sprint and choose the most important ones
• once the Backlog Issues are estimated and chosen, assign them to people to work on

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:

• less than 4 hours in duration to complete (feel free to use the time estimate/time spent feature if you want to improve your estimation skills)
  NOTE, make sure to include coding that is not directly related to a new feature (e.g., refactoring, testing, debugging, or spiking) as well as non-coding time (e.g., meeting, planning, etc.)
• assigned a weight (its complexity (Story Point estimate), not its time)
• assigned to a team member (based on the number of hours they can commit to the Sprint)
  NOTE, if the same or similar Backlog Issues need to be done by multiple people on the team, create one Issue per person for that task

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:

• gives your team a better understanding of the work involved
• prevents a team member from being over or under loaded
• easier to assign/reassign smaller issues versus large issues
• makes it easier to complete what was planned in that Sprint
• provides more accurate status of how the Sprint is progressing
• easier to make adjustments to the Sprints based on Client feedback, providing better customer service
• publish more accurate schedules to the Client and better manage expectations with them

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.