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.

When discussing a PBI/Issue, Pull Request, or a project in general, it is important to do it in the right place.

Key updates on projects may include Done Videos, critical text additions, or specification documents. Typically, links to these deliverables would be added to the PBI that they relate to and the relevant people would be mentioned.

There are many ways to write tasks in PBIs, but the best way is to use tasklists. This allows you to see the progress of the PBI at a glance as well as avoid any unintentional tasks being tracked. Below is the different ways you could write tasks in PBIs.

PBIs/Issues, tasks, PRs and goals are the backbone of work regardless of whether they are stored in Azure DevOps, GitHub, Jira, Trello, or some other platform. When you finish a task, marking it as done is satisfying, but remember to add a closing comment for future context. This allows others to understand the PBI was closed and what the outcome was.

Reading ugly commits is not very pleasant and makes it very confusing when you have to check the commit history.

GitHub provides a way to link issues to PRs. This is useful to see what PRs are associated with what issues. However, when you make this link, the issue will close when the PR is merged.

This is not a good idea because it can cause Issues to be closed prematurely. This can lead to confusion and lost work.

Luckily, GitHub provides a way to avoid this auto-closing behavior by disabling it in the repository settings.

You can use teams within a repository to manage a whole group's permissions instead of setting permissions for each new member of the organisation.

See Organizing members into teams.

✅ Figure: Good example - Using a good teams structure to organize access

Correctly configuring your organisation's teams structure will make it easy to give members the permissions level that they need. You can add teams to repositories to manage their roles.

✅ Figure: Good example - Using teams to assign roles in a repository