Skip to content

Community: Sprint planning process

Charlie Drage edited this page Feb 1, 2022 · 1 revision

How odo sprint planning works

  • 3-week sprints
  • Planning happens using Github Projects boards https://github.com/openshift/odo/projects
  • "For Consideration" column is for "pre-planning". Issues are first put into this column and then the team decides which one they can take up for the upcoming sprint and put them into "To Do" column.
  • Every issue in "To Do" column needs to have a clear definition of the work that needs to be done.
  • Every issue in "To Do" column needs to be sized (points/*) label
  • No issue in "To Do" should take longer than one sprint to complete

Sprint planning poker (task sizing)

  • 1 point represents 1 working day
  • Sizing should happen before the issue is assigned
  • Things to consider while pointing an issue:
    • Code work
    • Tests (Integration and unit)
    • Documentation

Planning calls

Preparation and Issue Triage (Monday on 1st week of a sprint)

  • Board for the last sprint is reviewed, incomplete tasks are either moved to the next sprint or put back to the backlog.
  • Issues that the team would like to address in the next sprint are placed into "For Consideration".
    • The team should review all priority/high kind/bugs issues and if possible address them in the coming sprint.
    • The team should review the active milestone and, if possible, try to move forward on the issues from the milestone.
  • All issues in "For Consideration" are reviewed, and the team makes sure that the definition of the work is complete (it has valid and actionable acceptance criteria).
    • If the issue doesn't have actionable acceptance criteria, one of the team members is assigned to do the research and complete acceptance criteria before the sprint planning call. Such issue is labelled with triage/needs-information.
    • Once the team member is done researching the issue and has added actionable acceptance criteria, they should add the label triage/ready and remove the label triage/needs-information. Also, the team member would disown the issue at this point.
  • The team member assigned to do the research doesn't have to be the same one who is going to complete the issue.

Sprint Planning (Wednesday (for QE), Thursday (for Dev) on 1st week of a sprint)

  • Spill over issues from the previous sprint should be repointed first, as that helps estimate the available bandwidth of the team member.
  • Next, team picks issues from "For Consideration" (at this point all issues in this column should be actionable (have actionable acceptance criteria))
  • For each issue, team votes and estimates the number of points for the given issue (no one is assigned to the issue yet).
  • If any issue scores more than 10 points, it is clear that it is bigger than one sprint, and it should be broken down into smaller pieces.
  • After all the issues are pointed, the team decides who is going to work on this. The decision should be mainly made on individual person's capacity.

Backlog grooming call (every week, except 1st week of the sprint)

  • The team checks new issues that were opened since the last Grooming call and tries to make sure that the issue is actionable (has valid acceptance criteria).
  • At the moment, we are using this call more for the sake of figuring out what to pick for next sprint. We do this by adding issues to "For Consideration" pile of next sprint's project board. But, eventually, we should be able to go through more issues and refine the backlog.