Welcome to the NZRT Wiki Podcast. Today we’re looking at 📊 Project Boards.

If you’ve ever wondered how NZRT keeps track of all the moving parts in a software release — from idea through to deployment — this is the episode for you. GitHub Projects are the tool we use, and they let you organise issues and pull requests into a visual workflow that the whole team can see and act on.

Let’s start with the two main ways you can look at a project board. The first is the Table View, which works a lot like a spreadsheet. You can see all your items in rows, with custom columns for things like who it’s assigned to, what the status is, and how high the priority is. The second is the Board View, which is a Kanban-style layout — columns running left to right, with cards you can drag between them. The standard columns you’ll see are Backlog, In Progress, In Review, and Done.

One of the most powerful things about GitHub Projects is automation. You don’t have to manually move things around all the time. The board can be set up so that new issues automatically land in the Backlog the moment they’re created. When a pull request is raised, it jumps straight to the Deploy column. When a PR gets merged, it moves itself to Done — and if there’s a linked issue, that gets automatically closed too. A lot of admin just takes care of itself.

You can also filter the board to show only what’s relevant to you — by status, by assignee, by label, or by priority. And if you need to update a bunch of items at once, bulk actions let you select multiple cards and change priority, add a label, or reassign them all in one go.

Let’s look at a real NZRT example. We have a board called the Dolibarr Custom Release Board, set up for version two point one. It has six columns. Backlog, for things not yet started — like a feature request for product export. Design, for anything in design review — for example, mockups for a comparison widget. Development, for work currently in progress, like actually building that comparison feature. Testing, where items are going through QA validation on staging. Deploy, for things ready to release but waiting on a second approval before merging to main. And finally Done, for everything already shipped — like version two point zero, which is already in production.

The board also uses custom fields to add more detail to each card. There’s a Priority field with High, Medium, or Low options. There’s an Effort field using story points — one, two, three, five, or eight points. There’s a Release field to tag which version something belongs to. And there’s an Owner field to assign work to specific team members.

Now let’s talk about sprint planning. Say you’re planning the sprint for a particular week. You go through your backlog and look at what’s available. You might have four issues to consider: one for advanced filtering at five points and high priority, one for improving mobile responsiveness at three points and medium priority, one for API rate limiting at eight points and high priority, and one for documentation updates at three points and low priority. Your sprint capacity for the week is thirteen points. So you’d pick the filtering issue at five, mobile responsiveness at three, and documentation at three — eleven points total — keeping two points in reserve for bugs or unexpected interruptions.

When you’re working day to day, you can filter the board to show only your assigned items. Instead of seeing everything, you’d see just your slice: maybe one item in Design, two in Development, one in Testing, and a collapsed list of whatever you’ve finished that sprint. It keeps your view clean and focused.

Bulk actions make light work of repetitive updates too. Say you’ve selected two items — a bug fix and a mobile responsiveness task. You can set both to High priority, add an urgent label, and assign them to a team member, all in one step rather than editing each card individually.

So to pull it all together: project boards give you and your team a shared, real-time picture of where work stands. Automation reduces the manual overhead, custom fields add the context you need, and filtering keeps your view focused on what matters to you right now. Whether you’re planning a sprint or tracking a release, this is how NZRT keeps things moving forward.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.