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

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

But the quick summary is:

• creating Issues before you do the work, including assigning them to a Milestone (Sprint)
• moving and tagging those issues on Gitlab's Issue Board
• closing or updating issues with your commits or Merge Requests
• labeling 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.

Starting the Sprint

Groom your Backlog by considering the following:

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

The result of this planning should be an updated Backlog in Gitlab

Planning Collaboratively

Now 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 provide end-to-end value for your users (so that a little bit of all "levels" are represented)
• For each category, estimate its complexity (e.g., using Planning Poker online or some other means to reach collective agreement) and decide 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

Documenting 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 (feel free to use the time estimate/time spent feature if you want to improve your estimation skills)
  Do not forget to include coding that is not directly related to a new feature (e.g., refactoring, testing, debugging, or spiking) as well as 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.