Rules to Better Scrum using GitHub (Issues and Projects)

GitHub Issues offer a great way of raising Issues within projects. However, it can be difficult to distinguish whether the Issue is a bug, feature request or just a question. GitHub Issue Templates should be used to help standardize Issues and ensure they have enough information for a developer to start work.

The templates also make it easy for people to write good quality issues, increasing the chance of getting good feedback and suggestions from users.

Let's take a look at how implementing Issue Templates can improve repository backlogs...

GitHub is an awesome place to manage your code, but initially it wasn't the easiest place to manage Scrum. Things improved in 2021 with GitHub Projects.

GitHub Projects lets you create Sprints and manage Issues (aka PBIs or Tasks) with far more power.

Prior to your meeting with the customer you should prepare. Get your Sprint Planning (was Release Plan) email ready, so after the meeting you can adjust and promptly send it.

Labels are an important way of categorizing your GitHub Issues. However, it is critical to make sure they are useful, clear and do not overwhelm users.

The goal is to use consistent labels across all repos.

Let's take a look at how to make a simple, yet information rich set of labels...

It is important that you, especially a developer, knows how to use labels for GitHub issues when using an open source project on GitHub, as it would help compact issues and make the issue management workflow more efficient. Essentially, having such a predictable workflow will let the community feel professional.

If a Product Owner sends an email to the development team with a request, that email should be turned into a Github Issue before any work is started or the work is prioritized on the backlog.

Power Automate has a connector to do this automatically when an email arrives in Outlook. It can create a new Github Issue by parsing the From, To, Subject and body of the email.

However, at the moment there is a limitation that it doesn't read inline attachments in emails and therefore you have to create your issues manually in Github.

When an Issue or Product Backlog Item (PBI) is created, it's important that team members review the title and content to ensure it is clear and correct.

The goal is always to complete Product Backlog Items (PBIs) for the Sprint Review.

Often PBIs grow or change and it does not make sense to deliver what was originally proposed in the Acceptance Criteria.

All good Scrum teams have a backlog. The backlog is built by taking a conversation and recording it as one or more Product Backlog Items (PBIs) (e.g. Azure DevOps) or Issues (e.g. GitHub, JIRA).

You should create PBIs during or straight after the conversation, rather than using emails that may never be entered into the backlog.

Figure: Get typing during a conversation to make the meeting tangible

The Product Owner is responsible for owning the Product Backlog. See the video on "Do you know how to be a good Product Owner?"

Although these requirements come from the Product Owner, it is often the developers who will record these PBIs.

If you store all your code in GitHub, why not create all your issues there too?

You might be reluctant to move your backlog to GitHub from Azure DevOps as you don’t want to lose the metrics functionality.

But you can easily sync all your GitHub Issues to Azure DevOps automatically to have the best of both worlds.