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
  • Cadence on analyzing Zenhub reports
  • When to use releases vs projects on the roadmap
  • The differences between sprints, 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 a way for you to plan out your goals, or groupings of related issues. Epics themselves 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 break down 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 vary 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?

The best way to manage and find epics is within the Epics Page or within the Roadmap and the Epics list view. 


When to use a checklist, Issue, Epic, or Project?

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-dos. 
  • 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 labeled through the use of Epics, help teams determine the scope and keep your roadmap on track.


Learn more about the specifics around managing lists, issues, and Epics.


What’s the difference between tracking project work in a sprint and the purpose of a release report?

Sprints help teams plan short iterations and organize issues against a single deadline. Sprints 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 sprints, 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:

  • Sprints help teams plan short iterations and organize issues against a single deadline.
  • Sprints are also helpful for time-boxed efforts where there are 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 sprints, releases help teams forecast delivery dates based on continuously evolving requirements. They help with the management of long-term work 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.



When to use releases vs. projects on the roadmap?

Depending on the information you'd like to track and visualize, you can use projects on the roadmap,  release reports or you can use both to share information in different ways:


Projects on the roadmap allow you to group related Epics together and act like folders for your Epics. Projects are designed to provide a broad overview of the key objectives or initiatives that are in progress / planned. This provides key stakeholders with instant high-level visibility into the progress of initiatives happening across the organization.

The release report is another way to track work with more granular information presented than the roadmap. Releases work like a "burn-up" report, outlining the total scope of work and how much has been completed to date. This report highlights scope changes in detail, dynamically updating as issues get added and removed to calculate a predicted end date.


Summary takeaways:

  • Projects on the roadmap help communicate, at a high level, the progress of all initiatives happening across the entire organization. Stakeholders can understand and visualize, at a glance, how current work is progressing and the future company direction.
  • Release reports are used to track scope changes in detail and help forecast delivery dates. You can add or remove issues directly from the release to understand how cutting scope or additional requirements being added will impact delivery.