GitHub Issues - Do you create templates for Sprint Reviews/Retros/Forecasts?

Last updated by Rick Su [SSW] 4 months ago.See history

This rule has been archived
Archived Reason: Moving to Email (Do you create a Sprint Review/Retro email?) due to GitHub Issues' shortcomings, cluttered backlogs, necessity for private repos in public projects, and limitations in scope management.

Sprint emails can be painful because you need to copy and paste data. Moreover, you can easily lose visibility of all your past Sprints.

GitHub issue templates help solve this problem by standardizing the format and location of Sprints.

Let's take a look at how...

Creating an issue template for both your Sprint Review/Retro email and your Sprint Forecast email gives you several advantages.

  • Users don't need to copy and paste the template, they simply press "new" and are prompted for information.
  • Visibility of all past Sprints is shown in the GitHub issue history
  • Let's you edit with Markdown
  • Standardizes the Sprint Forecast and Retro/Review process and information included
  • You still get an automated email from GitHub, so you don't lose anything by making the switch!

Make your GitHub issue templates follow the format of the rules on Sprint Forecasts and Sprint Reviews then you are good to go.

Give your Sprint issues a special "Sprint" tag so they can be identified in the backlog. Alternatively, you could store them in a separate repo which keeps them apart from your others issues and lets you keep the Sprint emails private if you don't want them in your public repo.

Figure: Bad example - Sprint emails can easily become inconsistent and lost in your inbox

Figure: Good example - With GitHub issues it's easy to spin up a Sprint Review or Forecast template

Figure: Good example - Editing a Sprint Forecast or Review/Retro is super simple and enabled with Markdown!

We open source. Powered by GitHub