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:

• 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

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/BACKLOG.md as a team, “refining” its description by asking the following questions:

• Is this issue still relevant?
  If not, you can omit it from Gitlab.
• What priority should we assign to this issue?
  Consider both how important this issue is to achieving your project’s goals and the order in which these issues need to be resolved — do other important issues depend on this issue?
• Does the issue have sufficient detail such that we will all know if it has been completed?
  If not, and the issue is high enough priority to be a candidate for this Sprint, then discuss it as a team and add the results of the discussion to the issue description (possibly making new issues). If this issue is not high enough priority, simply add a comment about any outstanding questions and move to the next issue.
• Have we made any decisions that change the scope of this issue?
  If so, update the issue description to account for this change. You can also use Issue Comments to note the change.
• Are there any new features, use cases or goals the team has discovered?
  If so, create new issues capturing these requirements, considering all of the refinement criteria above.

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:

• Complete: there are no Feature Requirements your team intends to undertake during the next month that is not on the Backlog
• Prioritized: every item is roughly sorted by priority

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:

• priority::low
• priority::med
• priority::high
• priority::critical

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

BACKLOG.md

Now, migrate your from docs/BACKLOG.md 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.

SPRINT_MILESTONES.md

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 SPRINT_MILESTONES.md 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:

• if the Issue helps accomplish the Sprint Goal
• if other high priority Issues depend on this Issue being completed
• if completing the Issue now is high enough value on its own to justify its inclusion

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:

• give your team a better understanding of the work involved
• prevent a team member from being over or under loaded
• are easier to assign/reassign (versus large tasks)
• make it easier to complete what was planned in that Sprint
• provide more accurate status of how the Sprint is progressing
• are easier to adjustment to the Sprints based on Client feedback, providing better customer service
• produce more accurate schedules to the Client and better manage expectations with them

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:

• determine if it is likely to take one person more than one day to complete. If so, break it down into smaller parts (i.e., create multiple issues)
• play Planning Poker to reach collective agreement on how much work the item is

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:

• Does this scope ultimately accomplish our Sprint Goal?
• Will we be prepared for the demo if we complete this scope?
• Does the team have enough capacity to complete these items?
• Are we omitting anything that will cause us problems down the road?

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.