GitHub for Project Management — How to Organize and Track Your Agile Processes

Editor’s note: This article is an excerpt from our newly revamped eBook: Project Management for Teams in GitHub. For the full guide to building a high-performing, agile software team, pick up your free copy!

This article has been updated on June 2021. Originally posted on www.zenhub.com

What is Agile?

Agile development — or simply Agile — is an iterative approach to software development that emphasizes flexibility, interactivity, and a high level of transparency.

Agile projects involve the frequent release of usable code, continuous testing (quality), and acceptance that whatever you think you know now, it’ll change (reality!). With a few tweaks and some basic understanding of best practices, you can turn GitHub into a powerful Agile platform…and reap the sweet, sweet benefits of the GitHub data your team is already creating.

GitHub is actually perfect for Agile project management

GitHub reinvented what it means to collaborate on code. They championed a new era of open source development, which naturally transitioned into a profitable business driven from the ground up by developers who love the platform.

If something has code, there’s a good chance it was developed or refined on GitHub. It’s where the world’s top software teams write, collaborate on, and ship amazing products.

The issue of focus: How most project management tools fail developers

As GitHub took over the development world, project management companies rushed to integrate with it as an attempt to bridge management and development teams. But every solution shared the same problem.

They all “live” outside GitHub, forcing developers to jump from tool to tool to update tasks, tickets, and reports. The result is “context switching”, and it’s much more costly than we expect.

People, as a rule, are terrible multitaskers. A study by the Journal of Experimental Psychology found that people who multitask see a 40% drop in productivity. When interrupted from a task, it takes 20–30 minutes to refocus. Switching between low-performance tasks — say, texting a friend while watching TV — isn’t too difficult. Getting back to where you were before (zoning out in front of Netflix) takes nearly no time at all.

But when tasks are complicated, the cost of context switching skyrockets. Consider a developer in the middle of coding a new feature. Here, a five-minute interruption takes much longer than five minutes.

Steve Fenton puts it this way:

“If a developer is interrupted with a question, it could put their work back by hours for each interruption. This is because of the amount of stuff they are holding in their immediate memory while they are working on a feature. They will have parsed lots of code in the area they will be working on and will have projected their changes in their mind before they start coding and the interruption will impact their focus on this information. Once interrupted the developer may decide to batch other interruptions like email into the break — but this elongates the gap and makes it more likely that the information will be squirreled away into harder to access places.”

In short: context switching is bad.

As a team lead, your role should be to shield your development team from distraction away from the code. Your business will be better for it — trust us.

“It’s important to respect that the type of work we expect devs to do requires some degree of recurring isolation to do it well,” says Christopher Hawkins, project management blogger and founder of Cogeian Systems. “A good manager runs interference against anything that might compromise developer focus, while actively soliciting any resources the developer might need.”

How ZenHub helps

There’s a reason we built ZenHub, and it relates to why we wrote this book. It’s not enough to instruct, hope, or pray engineers to stay focused. As software-driven companies, everything — down to the tools we use — should reinforce our commitment to the software first. This is why we created a tool that brings the project management and product roadmapping process inside GitHub. Not close to, not “integrated with”, but inside.

Centralizing your team in one system carries other benefits, like:

More accurate metrics

• Third-party tools result in silos of information. ZenHub lives where the code lives — inside GitHub. This gives you the most accurate view of what is really going on in your workflow and progress towards the project.

Focus on product, not process

• Project managers shouldn’t spend their day reminding coworkers to update tickets. When everything is centralized, project managers spend more time managing the project, and less time worrying about the people building it.
• Processes are important to streamline communication and promote team cohesion, but too much process can bury you in busywork while the important tasks go neglected. ZenHub’s automated features let you automate repetitive planning and administrative chores so you can focus on your real work.

Collaboration as a habit

• GitHub Issues were built for collaboration. Collaboration not only helps reduce error and technical debt, it actually keeps teams happier. In one study, enterprise companies that identified collaboration as the top priority significantly improved employee satisfaction, customer retention, and productivity (Aberdeen Group, 2013).

Total team alignment

• In most organizations, key stakeholders across the entire company have no clue how far along their software projects are on the product roadmap. On another hand, the costs associated with setting up and maintaining roadmapping tools can be a financial burden for many organizations. This often results in the use of spreadsheets that quickly end up out-of-date and require manual effort to maintain. More importantly, most product roadmapping tools only offer lightweight integrations that aren’t tied back to changes happening in the code.

More than Issues: Setting up an Agile process in GitHub

Like a message board for your ideas, Issues are GitHub’s task-tracking system, used to log bugs and scope out new features. Issues provide a place to talk about the amazing software you’re building.

Image via GitHub.com

But in their default state — organized in a list — it’s difficult to glean important information about issues in a glance. You can’t easily understand their progress or their priority.

ZenHub’s extension and Web App adds a crucial layer of prioritization and planning to GitHub Issues.

Agile process in GitHub

Sprint → Sprint

In Scrum, sprints are a fixed length of time during which an agreed-upon chunk of work is completed and ready to be shipped. You can easily build sprints within ZenHub, either manually, by using our sprint automation features, or with a mix of both.

If you plan your sprints at regular intervals (at Zenhub we do every two weeks), you can set up ZenHub to automatically schedule a sprint to begin at the same time every cycle.

ZenHub can also automatically populate your sprint with issues from the product backlog based on your team’s average working velocity. Likewise, at the end of a sprint ZenHub will automatically carry any unfinished issues over to the next sprint. No longer will managers dread the tedious work of pulling tasks from one pipeline to the next. Instead, they’re freed up for higher-leverage work and other priorities, like snacks and naps.

User Stories → GitHub Issues

User stories are high-level feature descriptions that help define benefit from a customer’s perspective. They’re often written in the following format, which is intended to keep things simple and focused on business value:

As a <user type>, I want <a goal> so that <benefit>.

If you’re adhering to this structure, make it your issue’s title. You can also set up GitHub issue templates to add detail or acceptance criteria when the time comes.

Epics → Epics

No need to map this one: ZenHub provides Epics inside GitHub. Epics help teams plan and collaborate on product backlogs; they’re essentially just big user stories (for example, “Dashboard Redesign” would be an Epic, while “Change CTA color” would be an issue within that Epic.) Using ZenHub, you can map out a big chunk of work using Epics, then add related issues to flesh it out.

Epics have flexible scope, so you can add, edit, and remove issues as needed. Once you’ve set up an Epic, you can track it alongside your other work in your task boards. Or, filter by Epic to track only those Issues.

While sprints chunk work out by a specific amount of time, Epics group work by a larger goal or feature. For example, if a sprint represents a two-week period of work, an Epic might map out an entirely new feature involving dozens of issues. It will probably take more than one sprint to complete an Epic. Alternatively, you might work on a few Epics concurrently in one sprint!

Product Backlog → Open issues without a sprint

Your product backlog includes, well, pretty much everything. Typically ordered vertically by each issue’s business value, ours is a collection of user stories, half-baked feature ideas, things we might do in the future, technical work, and anything else. The point is to make a habit of getting stuff out of your head and into GitHub. Be honest with yourself, though: if it’s never going to get done, it’s best to close the issue.

Sprint Backlog → Issues within a sprint

Your sprint backlog contains the work your team has committed to tackling in a given sprint. Issues here should be estimated, include detail, and have a sprint attached. They should be vertically arranged by priority in this pipeline.

As we’ll discuss in the product backlog chapter, you can use the Icebox pipeline to “freeze” stories that aren’t a priority, and the Backlog pipeline to prioritize issues for multiple sprints. When a team member is ready for a new task, they simply filter the board by sprint, then drag issues from the Backlog to In Progress pipelines.

Note: Beware of scope creep. Once a sprint begins, your issues should remain fixed.

—

Download our free eBook to continue reading about how your team can bring project management right into GitHub with ZenHub.