6  Sprint Planning

Each section of the sprint meetings will be timed. The Timer is responsible for setting a timer to indicate when the time is up, though the group may collectively decide to continue a conversation.

Running notes from sprint planning and retrospective

6.0.1 Roles

Roles are pre-assigned to different group members (e.g. by this script) in this Google Sheet.

  • All Team Members: Share their own screen when it’s their turn to review their tickets, progress, and point estimates
  • Timer: Keeps track of time spent on each section of the meeting and tells group when it is time to move on.
  • Scribe: Keeps track of todo list on HackMD including:
    • new issues to create
    • issues that need to be broken up into smaller tasks
    • follow-up discussions and meetings that are proposed.
  • Leader: Keeps group on topic and on schedule, lets the scribe know when to make a note of something if not already done, and generally directs the flow of the meeting.

6.1 Sprint Review/Planning

In October 2020 we decided to combine Sprint Review and Planning into a single, 1.5 hour biweekly meeting, scheduled for 10:00-11:30 am on Fridays.

The goals of this meeting are:

  • Keep group up to date on new tools, products, and accomplishments
  • Review previous sprint and identify where we are stuck
  • Compare estimates with reality, and review progress and velocity
  • Plan next sprint

6.1.1 Process

6.1.1.1 Pre-meeting preparation

  • Move completed issues to ‘Done’ column of GitHub board
  • Done issues should include a brief description of the outcome(s) that may include:
    • Link to merged pull request
    • Links to output such as documentation, datasets, etc
    • Figures and screenshots
  • Incomplete issues are either
    • moved to done with a description of what was completed and links one or more new issues containing the remaining tasks
    • changed to an epic with sub-tasks
    • if little or no progress has been made, bumped to next sprint
  • Review previous Sprint meeting notes for unfinished TODO items
  • Create new sprints on GitHub board…

6.1.2 Meeting outline

6.1.2.1 Part I: Review

  • 2 minutes
  • Demo (10 minutes)
    • someone demo something accomplished; this should be assigned at the previous Sprint meeting
    • Choose demo presenter for next sprint
  • Review (30 minutes)

    • Each team member will share their screen and review their work from the previous Sprint:

      • Select previous sprint time period under sprint filter drop down
      • If there are any remaining New, Ready, or In Progress issues (which there should not be any), they should quickly be dealt with
      • Review all Review/QA and Done issues
        • If there is not a sufficient description of the issue or its resolution, close the issue but add a note to HackMD for the issue owner
      • Discuss estimated points vs actual effort. Team members can explain and change point values at this time, before closing
      • Move completed issues to Closed
  • Close - if issues are under Sprints, they are not closed automatically on the last day of the Sprint and need to be manually closed. There is a “cleanup” view on our board to help facilitate this.

6.1.2.2 Part II: Planning

  • 5 minutes
    • On your own / optional break
      • Write new issues individually
      • Should reflect group discussion, particularly on collaborative projects
      • Check to make sure all issues have clearly defined steps and outcomes
      • Identify any outstanding PRs and create issues to have them reviewed as necessary.
  • 15 minutes
    • Each team member will share their screen and review their work for the subsequent Sprint:
      • Select current sprint milestone under milestone filter drop down
      • Briefly discuss each issue, the outcomes, point value, and how others might help
  • End with gratitude towards team members

6.1.2.3 Part III: Report review

  • Do this after the sprint is over, during Monday’s standup
  • Charts (10 minutes)

    • Review reports (called “insights” on GitHub project board). The leader should share their screen and go through the reports.

    • Burndown report

      • Open issues should go down at a steady rate and be replaced by completed issues
      • Should end with 0 open issues
      • If not, discuss why not

    • Cumulative flow

      • Shows number of open issues in last 3 months
      • Make sure no one status is getting substantially larger (this chart is currently broken and doesn’t break down issues by status)
      • Make sure we aren’t accumulating too much too quickly—we should get toward steady state or know why not

    • Velocity tracking

      • See if we are going at a consistent pace
      • Make sure that scope of next sprint is feasible given running average pace