Help Center

A collection of questions that span multiple areas of ZenHub related to:

  • Managing projects using Epics
  • Best practices for adding project work into Sprints
  • How to interact with Epics on the Board
  • Cadence on analyzing ZenHub reports
  • And, the differences between Milestones, Releases, Epics, and Issues


How do Epics and Sprints work together? 

Only accept Issues and smaller pieces of work into the Sprint, don't add the Epic into the Sprint. Epics are large bodies of work, or groupings of user stories. Epics should not be estimated, but instead help teams understand large scope projects. The Epic is like a landing page of tasks that make up larger work projects, acting as an information beacon.


When accepting work into the Sprint, be sure to breakdown Epics into smaller Issues that can be estimated and discussed. Smaller pieces of work are easier to understand, de-risk from having unknown blockers that might not be present during Sprint planning, and can easily be moved throughout the Board and closed quickly.


Sprints should have fixed scopes, and as Epics are meant to be larger pieces of work, their scope can very and change over time. Keeping flexible scope in an Epic is important to allow projects to evolve over time, but Issues should be as small as possible to keep the team moving forward without uncertainty.



Summary takeaways:

  • Issues within the Epic should be going into the Sprint, but not the Epic itself
  • Fixing scope in a sprint allows teams to focus on what is important in the short term
  • Epics allow for tracking flexible scope in a project, without losing track of the entire scope of a collection of work


Where do Epics live on the Board? (Epics Pipeline)

The best to manage Epics on the Board are to create a designated home in a pipeline. We recommend two pipelines helps organize Epics: Epics and Priority Epics. Epics aren’t meant to move throughout your Board, but be the vessel to help you track user stories and key projects in a central location.


Having a designated pipeline for Epics, as well as Epic Priorities helps the team understand what is a continuous project, versus one that is actively moving forward. We recommend using the Priority Epic pipeline for work that is actively moving forward within the next 3 months. 



Summary takeaways:

  • Create designated pipelines for Epics, then Epic Priorities (Priority Epics are those you're working on within the next 3 months)
  • Epics aren’t meant to move throughout your Board, but be the vessel to help you track user stories and key projects


When to use a checklist, issue, epic or projects?

ZenHub helps teams manage projects at scale, enabling multiple teams to collaborate and have ownership over the project planning process. Using GitHub Issues and ZenHub Epics, you can track tasks, large scale projects, and even small to-do lists.

  • Checklists within Issues allow teams to understand how they're progressing on to-do's. 
  • Issues track specifics the team is working on, keeping teams aligned on work in progress.
  • Epics make it possible to organize information and keep track of how GitHub issues roll up into larger projects and initiatives.
  • and projects, as labelled through the use of Epics, help teams determine scope and keep your roadmap on track.


Learn more on the specifics around managing lists, Issues, and Epics.


What’s the difference between tracking project work in a Sprint using a Milestone and the purpose of a Release report?

GitHub Milestones help teams plan short sprints and organize issues against a single deadline. Milestones are also helpful for planning sprint work, or time-boxed efforts where there's limited to no scope changes.Releases on the other hand are used for long-term business goals, tracking scope changes for external commitments, or any project work that spans across multiple sprints or has a long timeline. Unlike Milestones, Releases help teams forecast delivery dates based on continuously evolving requirements. 


They help with management of long term initiatives because they give teams forecasting abilities that help teams manage risk. By highlighting scope changes, and dynamically updating as Issues get added, removed, and completed, Releases show how scope changes impact deadlines. Learn more


Summary takeaways:

  • GitHub Milestones help teams plan short sprints and organize issues against a single deadline.
  • Milestones are also helpful for planning sprint work, or time-boxed efforts where there's limited to no scope changes.
  • Releases can be used for long-term business goals, tracking scope changes for external commitments, or any project work that spans across multiple sprints or has a long timeline.
  • Unlike Milestones, Releases help teams forecast delivery dates based on continuously evolving requirements. They help with management of long term initiatives because they give teams forecasting abilities that help teams manage risk. By highlighting scope changes, and dynamically updating as Issues get added, removed, and completed, Releases show how scope changes impact deadlines.


Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.