This is the first post in a series on how to do Scrum with GitHub Projects. My plan for these posts is to help you not just figure out how to do the project management stuff but – more importantly – I want to show you ways to streamline your delivery process.

By the way, I'm also doing a video series on Scrum with GitHub Projects on YouTube. If you want to watch the video version of this post, it's available here.

The Scrum Framework

Now I've been a Scrum.org Professional Scrum Trainer – also known as a PST – for something like ten plus years. The image above is the Scrum.org diagram of the Scrum Framework. Scrum is one of the extremely common ways to deliver software or deliver products using an “agile” mindset. The basic gist is that you have an idea, you break the idea down into features that you'll deliver, and then you'll work in chunks of 30 days or less to gradually deliver those features. That's the super-simplified version of Scrum but if you'd like to learn more, you might want to check out my Scrum in 20 Minutes or Less video on YouTube.

What do we need to support Scrum & Agile?

I'm going to focus on all this from a software development perspective. So let's talk about what we'd typically need to do in Scrum and how you'd use GitHub Projects (or GitHub in general) to support those activities.

Ok. Let's think about the core project management activities that we'd need to do if we're working on a Scrum project - And to be honest, not just a scrum project…you'd need to do stuff like this on any project…but at a minimum, what do we need?

We've gotta know what we're planning to do: That's our list of requirements.

Big bonus points for having these requirements prioritized. Ideally, the stuff that brings the most joy or most value or most awesome-ness or most revenue or most business value…those should be at the top of your requirements list.

In scrum, this list of requirements is known as the product backlog.

The next big question is how many days do we have available? How many days can we work? What's our “capacity”?

This gets us towards answering the question of “how much stuff can we reasonably do” in a certain period of time. This period of time in Scrum is known as a “sprint”. Sprints are 30 days or less.

This capacity information leads into the Scrum “Sprint Planning” meeting where we plan out what we can do or are likely to do in a given Sprint.

You'll probably also want to know how you're doing on any given day. Because someone is probably going to ask you how things are going.

So we'll need to track progress and track the status of how we're doing in the current sprint.

Mapping this into Scrum, this is an activity that we'd probably care about in the “Daily Scrum” meeting. You'll probably care about this status info at a lot of other times, too but if we're thinking about just pure, strict, by-the-book, by the "Scrum Guide" Scrum, at a minimum, you'll care about this at the Daily Scrum meeting.

Enter GitHub Projects

And this brings us to GitHub Projects. GitHub Projects are new in 2024.

If you've been in the GitHub world for a while, you might be a little confused about how GitHub Projects relate to GitHub Issues.

GitHub Issues have been around for a while. They're good and helpful but they're also pretty bare-bones. You can do a lot but if you're getting into bigger, more complex projects...well...that's where GitHub Projects comes in.

A key thing to remember is that GitHub started as a version control company. Basically, giving you an easy place to host your Git repositories.

At GitHub, Git Repos are King

And as we move towards GitHub Projects and as GitHub Projects grows and matures, you're going to notice that Git repositories are king.

Pretty much everything revolves around either your account or a repository.

As you start to do project management-y things, this can get a little awkward because when you're doing project management, there often times isn't an obvious one-to-one mapping to a repository. In fact, your project plan and the activities described in your project plan might map to multiple git repositories.

It probably would be worth it for me to talk just a little bit about Git repositories and how they exist in the GitHub world. And remember, since repositories are king in the GitHub world, a repository isn't JUST a repository. It's got other stuff.

At its core, a repository gives you version control for your source code.

And when I say “repository” I mean a Git-based repository. Git being the version control system that is used all over the world that's at the core of what GitHub does. This is that essential mapping between Git the version control system and GitHub the service company.

Next: GitHub Issues

Issues are the original, very simple project management system that's been in GitHub for a long long time. An issue is basically just a title and a description plus a handful of other fields. They're simple to understand and simple to use. And they're powerful, too…but also limited.

Then another giant piece of the GitHub universe: ”pull requests”.

Pull requests are basically code reviews built on top of Git version control -- specifically "branching & merging". Create a branch in Git. Make a bunch of changes. And then when you're ready to share those changes back to your team or into your product or whatever, you can create a ”pull request”. That'll kick off a flow of pulling those changes into the main source code for the product. And it gives those people tasked with maintaining that product a chance to review what's changed, request modifications, and eventually accept or reject those changes.

And finally, we have GitHub Actions.

GitHub Actions is GitHub's automated build and release tooling.

Build your code. Test your code. Deploy your code. It's the automation at the core of your DevOps world. And from the perspective of Scrum or Kanban or whatever you're using for project management: this build and deploy automation is going to save you a TON of time.

GitHub Projects: GitHub Issues++

So. GitHub Projects.

These are the project management tools that are part of the GitHub ecosystem.

It's GitHub trying to go beyond the bare-bones features of GitHub Issues.

It's github trying to give us a full project management suite. If you're an "Azure Dev-Ops" user, it's GitHub trying to give enterprise project management tooling like you have in Azure Dev-Ops Boards.

Where repositories are king in the GitHub world, projects are meant to stand alone.

They're intended to NOT be part of a repository…

Well, until you need them to be part of a repository. Keep projects separate from repositories and issues and -- yeah – that's the idea.

Keep ‘em separate. Sorta. Kinda. For the most part. Yah. Separate. Mostly separate.

Ehhhh. You'll see what I mean once I start doing demos...

Enterprise Project Management with GitHub Projects

If you're managing big, complex projects -- if you're doing enterprise project management – what do you need?

If you're the project manager or the Scrum Product Owner or the Scrum Master or maybe even a team member: What are the key questions that drive your work? Here are the big ones.

The most basic: what do we need to do? What are the requirements and the details of the requirements?

What order do we need to do these things in? There are dependencies between items. There are priorities for items. There might be due dates for certain items. All of these things speak to the order of delivery.

Day to day and maybe even hour to hour or minute to minute, you'll probably want to be able to answer “what are we working on” on the team.

How's our progress? What have we gotten done? For the things that we're actively working on, how far along are we? How are we doing on due dates and deadlines and release schedules?

And then there's the longer term vision for the future. What are we likely to do in the future? What are we planning to do in the future? When are we likely to get certain features...

In my mind, when I'm working in a project management role...these are the questions that I'm going to need answers to. Basically the questions that I'll lean on a project management system for help with.

We'll also want our project management system to be able to ”surface” this information in a way that can quickly be understood and visualized.

Also known as “reporting”. We'll need a way to visualize all this stuff and ideally share these visualizations to our bosses, coworkers, customers, and stakeholders.

Next up...

So the stuff from this post is intended to give some context and now we can start actually doing demos.

Coming up in the next post and beyond: I'm going to show you how to do all this stuff using Scrum and GitHub Projects.

I hope this helps.

-Ben

-- Looking for help adopting GitHub Projects for your team or your company? Need an assist getting going with GitHub Actions for automated builds and releases? Want to move your stuff over to GitHub from another service? We can help. Drop us a line at info@benday.com.