CompSci 308
Spring 2024
Advanced Software Design and Implementation

Lab Team Meeting: Agile Project Management

In your OOGASalad teams, take some time to prioritize, organize, clarify, and assign the project's features that will be done the first 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.

In this lab, your team will:

  1. Refine your Backlog
  2. Create a Backlog in Gitlab
  3. Agree on Issues to Include in the First Sprint
  4. Kick off the Sprint

Notes on Class Agile Workflow

Weekly Demos

Each Sprint ends with a short in-class demo (approximately 5 minutes long) of the features added during that Sprint, delivered by 2-3 students. Thus, when planning your Sprint, ask “how would we demo this to the class?”

Gitlab Resources

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:

Refine your Backlog

Issues on your Backlog can be whatever your team agrees to, such as Use Cases, Feature Requirements, bugs, specific significant refactoring goals, or non-programming tasks (like improving documentation). Each Sprint is started by refining your Backlog, an ongoing process to ensure the issues are up-to-date and still relevant before you start working on those issues.

This is your first chance to go through each issue in docs/ as a team, “refining” its description by asking the following questions:

Next, sort the Backlog so that the highest priority issues are at the top, with each team member contributing (and thus agreeing) to the ordering.

At this point, your Backlog should have the following properties:

Before Moving On: Discuss as a group if you think your backlog is indeed Complete and Prioritized. If not, add any missing issues and prioritize them.

Create a Backlog in Gitlab

Before creating any Issues in Gitlab, you will create Labels, which will help you keep your backlog organized. Create at least the following Labels:

The priority labels give a rough sense of how important issues are, and will be used for organizing the Backlog in the next section. Additionally, you can also create Labels to track how issues relate to parts of your system (such as authoring, player, data, and engine). And later, you will likely create Labels for kinds of work that needs to be done (such as bug, refactor, and test).

Now, migrate your from docs/ to Gitlab Issues by creating a new Gitlab Issue for each of the issues you just refined. For each Issue, assign it a priority using the Labels you created.

Gitlab's Issue Board will be the one place to view the project's progress and work remaining to be done.

In this class, we will use a single Gitlab Milestone to represent a Sprint's worth of Backlog Issues by assigning them to each Milestone. You will refine the Sprint 1 Milestone in the next section.

If, as a result of this discussion, your team also decides on (tentative) scope for future Sprints, you can update the Milestone descriptions for those Sprints to document what came out of the discussion. This is not a commitment to a future Sprint scope — you will repeat this planning exercise for those Sprints — but it can save you time and help keep the team focused on incremental goals to have such a “roadmap”.

Before Moving On: Create Milestones for each Sprint (named Sprint 1, Sprint 2, …) and add the descriptions from your planning document to each.

Agree on Issues to Include in the First Sprint

To determine a Sprint's scope, you need to account for the time available to make progress (“capacity”), the priority of Backlog Issues, the amount of work it will take to complete each issue, the allocation of work across the team, and what you can demo at the end of the Sprint. You will walk through a process that helps you account for all of these factors in planning your Sprint. This process takes longer for the first Sprint than future Sprints.

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

You will consider the amount of capacity the team has available in the next section. For this section, you should be optimistic and select Issues based on a ‘best case scenario.’ You do not have to select items just based on priority — the priority:: label just helps you focus on a limited number of Issues instead of all of them (but you should likely not be including any priority::low items in this Sprint).

Select a Candidate Scope for the Sprint, where you will focus on selecting Issues by their priority by considering:

When you select an issue to include in the Sprint, set its Milestone field to Sprint 1. Continue moving down the backlog until you feel like you have selected that ‘best case scenario’ scope. You do not need to review every issue if you get there quickly.

Then, read the Sprint 1 Milestone description of what you originally planned to accomplish. Discuss as a team if these goals are still what you want to accomplish. based on the Issues now included. It can be helpful to frame the discussion in terms of what you would like to demo — but do not ignore design problems or technical solutions that need to be constructed for future features.

Pay close attention whether or not this goal aligns with the Issues you have listed as highest priority. If there is a difference, try to figure out why there is a disconnect. These differences often reveal important differences in understanding in the team, and resolving them can be the most effective planning that you do.

Before Moving On: Verify that Sprint 1 Milestone's description and Issues match the description to align with the outcome of your team’s discussion.

Refine the Candidate Scope Based on Team Capacity

Begin by discussing each person's honest capacity for this Sprint based on your outside of class activities (midterms, interviews, illness, etc.). You can use the Time Tracking field of the milestone to track the total number of hours the team expects to have available to work on this Sprint. This will be useful in planning later Sprints.

Now, you will estimate how much work each Issue will take to complete. Estimating the complexity of your tasks can be challenging so consider aggressively breaking down your Issues into issues as small as possible. Other benefits of smaller Issues are that they:

A good goal is to shoot for Issues that will take less than one day to complete. This includes work that is not directly related to coding a new feature (e.g., refactoring, testing, debugging, or spiking) as well as non-coding tasks (e.g., meeting, planning, etc.) Feel free to use the time estimate/time spent feature if you want to improve your estimation skills.

For each issue, do either or both of the following:

Once your team has agreed on the tasks’ difficulty, assign a weight to that task (the task's complexity, Story Point estimate). Along with the team capacity, you will use these weights to scope future Sprints. For now, you can treat a score of 8 as a full day of work.

In the end, the goal is to only plan work you can realistically complete given your Sprint capacity. If you selected an optimistic scope in the last step, this will likely lead you to remove Issues from this Sprint in this step. In that case, for each issue you decide to remove, set its Milestone to field to either blank or a future Sprint.

In the case where you have extra capacity, return to the backlog and select items by priority. This time, break the issues down and/or estimate their effort before you add them to the Sprint.

Before Moving On: Remove any Issues that you do not have capacity for from the Sprint by changing their Milestone field. If you have extra capacity, add Issues from the backlog by setting their Milestone field to Sprint 1.

Kick off the Sprint

Open the Issues view of your Sprint 1 Milestone. This will show you all the issues your team is planning on completing in this Sprint. Review the complete scope as a team and consider:

Assign each person at least one Issue to work on (by using Assign on the Issue in Gitlab).

Each member of the team should explicitly agree to the scope, i.e., by verbal acknowledgment. If there are any remaining questions about the scope, resolve them so that everyone can agree before moving on. This may include adding or removing Issues. Note: The goal of backlog refinement is to ensure everyone has a shared understanding of what the work is and who is responsible. It is normal to realize in this process that something is missing or misunderstood. If this happens, simply update the Backlog (by adding issues, changing priorities, embellishing descriptions, etc) to address the gaps.

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

Before Moving On: Signal the start of the Sprint by setting the Sprint 1 Milestone Start Date field to today and End Date field to one week from today.

Execute the Sprint

You should use the Issue board in your team meetings to retain a holistic picture of your team’s progress on the Sprint.

Use of an Issue manager is most 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.