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 useable code (revenue), 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 agile best practices, you can turn GitHub into a powerful agile platform...and reap the benefits of the GitHub data your team is already constantly creating.
We think anyone invested in the success of a GitHub project can benefit from managing that project closer to the code.
In this guide, we'll show you how to make the most of these features to move faster in GitHub, collaborate more efficiently, and visualize your software projects from beginning to end.
What are GitHub Milestones?
In Scrum, sprints are a fixed length of time during which an agreed-upon chunk of work is completed and ready to be shipped. Sprints, or “iterations”, are mirrored in GitHub with Milestones. A "sprint" can also be thought of as a way to bundle work together— work your team agrees can be completed within a specific time frame.
What are GitHub Issues?
In GitHub, Issues take the place of user stories – high-level feature descriptions that help define benefit from a customer’s perspective. Remember, once a sprint (Milestone) begins, their scope should remain fixed. Let's touch on what that means in practice.
User stories are high-level feature descriptions that help define benefit from a customer’s perspective. They're often written in this 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.
The point is to make the Issue well-defined for everyone involved: it identifies the audience(or user), the action (or task), and the outcome (or goal) as simply as possible.
What are ZenHub Epics?
In agile, a user story is the smallest unit of work, and an Epic is essentially a "big" user story or theme of work. If “as a customer, I want to be able to create an account” is a user story, the entire account management feature may be an Epic.
Epics also help teams plan and collaborate on product backlogs; they're big user stories or thematic groupings of work (for example, "Dashboard Redesign" would be an Epic, while "Change CTA colour" would be an Issue within that Epic). Using ZenHub, you can map out big chunk of work using Epics, then add related Issues to outline all the tasks related to completing a grouping of work.
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 ZenHub Boards. Or, filter by Epic to track only those Issues.
Note: In contrast to Milestones, Epics are not necessarily related by time. It can take several Milestones to complete an Epic.
GitHub repositories as project workspaces
Repositories in GitHub can be considered workspaces that help you organize projects, teams, and walls of work.
Your development team will already have repositories that correspond with the code that is being developed. Using this model, ZenHub leverages the Issues and work already in-flight to help you build your Board, refine your backlog, and track work where work happens.
Agile Release planning and Release reports
Releases and Release planning help teams manage scope changes across long-term projects or Milestones and better predict end-dates based on what work is happening. Having Release planning plays a critical role in the cycle of development—it supports goal alignment and issue management. Teams get visibility into development velocity to add a predictable layer of planning to deadline management.
Agile Release planning help teams deliver value to their customers, bundling the impact of each Issue, story, piece of code, and project in a central reporting view.
Releases help teams to:
- Increase and improve visibility into how new work can fit into already committed plans
- The progress of existing work and whether there are any outliers that are blocking deadlines
- Ensure continuous refinement of product backlogs
- Inspire collaboration discussion around acceptance criteria before adding additional work to scope once a project has started
- Provide a reliable visualization for teams and stakeholders to asses resource needs and risks to a project
Product backlogs and master story lists
Your product backlog, sometimes referred to as a Master Story List, 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.
A backlog is different than an icebox!
The Icebox represents items that are a low priority in the product backlog. We don't want to delete these and create a cycle of raising duplicate Issues, so we keep them in our icebox with just enough information attached that we can pick it up some time in the future -- if and when we choose to do so.
Icebox Issues should not take up a team member’s time or mental bandwidth; we find that putting ideas into the Icebox Pipeline gets them out of our heads and helps us focus on immediate priorities.
Sprint backlogs are Issues with a Milestone
Your sprint backlog contains the work your team has committed to tackling in a given Milestone. Your team can collaborate to add Estimates to Issues (by time or complexity), requirements, and attach a Milestone.
We suggest ordering Issues vertically by priority on your ZenHub Board. To groom things even further, use the Icebox pipeline to “freeze” stories that aren’t a priority, and the Backlog pipeline to prioritize Issues for multiple Milestones. When a team member is ready for a new task, they simply filter the Board by Milestone, then drag Issues from the Backlog to In Progress pipelines.
Note: Beware of scope creep. Once a sprint begins, your Issues should remain fixed.