Managing Sprints

For this course, we will use Gitlab directly to manage your project's tasks by

• entering each as an Issue
• assigning them to a Milestone (Sprint)
• monitoring your project's progress with its Burndown Chart.
• Tagging your relevant main branch commit with the Sprint's name (i.e., Prototype for the Prototype release) when you feel your code for the Sprint is complete

Starting the Sprint

Plan by breaking the work into small 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)
• assigned a weight (the task's Story Point estimate (complexity), 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 tasks need to be done by multiple people on the team, create one Issue per person for that task
• one of the following (or others if needed), each of which should have its own Definition of Done that the team agrees on:
  • coding. Described using either a Connextra (user story) or Gherkin (Cucumber test) template — note, testing and refactoring should be included in your estimate for each task
  • bug. Found after basic feature implementation using this template provided in your repository — note, new tests should be written to verify the bug exists and is fixed
  • spike. Used to find out more about an upcoming feature that has a high degree of uncertainty — note, this should be time-boxed to avoid becoming a time sink
  • non-technical. Described using either a Connextra (user story) (with some examples given in this discussion) or some other way that clarifies its value to the project

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

Finishing the Sprint

Meet as a team to reflect on the Sprint, groom the Backlog, and plan for the next Sprint (including determining what workload the team can handle). During this planning meeting, you should consider 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 Client asks
• create new Spike tasks to learn more about upcoming User Stories that are highly uncertain
• reassess the relative priority of all User Stories in Backlog with Client
• correct existing estimates of high priority User Stories in light of newly discovered information
• assign Story Point estimates to high priority User Stories which have yet to receive one
• split high priority User Stories that are too big to accurately estimate or to fit in an upcoming iteration
• agree on Definition of Done for high priority User Stories

The result of this planning should be an updated Backlog and the creation of a set of tasks you expect to accomplish in the next Sprint entered into Gitlab as issues.