Lab Exercise : Retrospective and Managing Your Sprints

Estimating the complexity of your project's tasks can be very challenging so try making them as small as possible and discuss them collaboratively. Breaking each task down means thinking about the all the sub-tasks that are necessary to get that one task done (since most people start with tasks that are too big). A reasonable, estimable task should actually be something you feel can be done in less than 4 hours (the longer your estimate the less people will trust it).

Submission

By the end of lab, push your discussion summary to the file doc/RETROSPECTIVE.md of the master branch of your team's provided Gitlab repository using the commit message "lab_retrospective - participating NETIDs".

Also, your Gitlab project should reflect the new and updated Issues made during the Planning steps.

Resources

As a 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
• Code Review via Gitlab Merge Requests

But the quick summary is:

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

Retrospective

Start by reflecting on your progress and goals as a team in order to improve your efforts (to work smarter, not harder). That is the fundamental goal of Agile and embodied in the Sprint Retrospective, considered by many to be the most important activity in Scrum. If done properly, Retrospectives can be a place where teams grow and deepen their trust; unfortunately, they can easily get derailed and turn blameful. Try to use this time to let it all out so nothing festers and try not to take anything said personally.

Address the following, possibly hard, topics openly as a team:

• discuss how each person feels about the project's current progress: is it ahead of, on track, or behind schedule?
• discuss how each person feels about the current level of communication: is it too much, just right, or too little?
• discuss how satisfied each person feels about their role on the team
• agree on two things about how your team functioned that worked well
• agree on two things about how your team functioned that could be improved
• agree on one thing you plan to improve next Sprint about your teamwork/process

Summarize the team's discussion for this part in the file RETROSPECTIVE.md.

Plan the Next Sprint

Groom your Backlog by considering the following:

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

The result of this planning should be an updated Backlog in Gitlab (i.e., set of Issues)

Plan Collaboratively

As a team, 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 create a set of tasks that need to be completed (for this step just try to list as many as possible)
• collect the tasks 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 tasks and compare it to the limit you think can achieve in this Sprint and choose the most important ones
• once the tasks are estimated and chosen, assign them to people to work on

Document the Plan

For each task now planned for this Sprint, break it down further into small sub-tasks that are:

• less than 4 hours in duration to complete (include coding not directly related to a new feature (e.g., refactoring, testing, debugging, or spiking) and non-coding tasks (e.g., meeting, planning, etc.))
• assigned a weight (the task's Story Point estimate (complexity), not its time) based on your work during the previous Sprint
• assigned to a team member (based on the number of hours they can commit to the Sprint)
  • note if the same or similar tasks need to be done by multiple people on the team, create one Issue per person for that task
• have a clear Definition of Done (which differs depending on the kind of task it is)

The result of this 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).

During the Sprint

By breaking tasks 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 tasks versus large tasks
• 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 the status of your Issues online through Gitlab or using keywords in your Git commit messages.