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
- 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 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.
- 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? (Goal pipelines)
The best way to manage epics on the Board is to create a designated pipeline for your goals being tracked with epics. We recommend two pipelines to help organize epics: Short-Term Goals and Long-Term Goals. 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 designated pipelines for epics helps the team to understand what is a continuous project, versus one that is actively moving forward.
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 ossues 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 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
- Sprints help teams plan short iterations and organize issues against a single deadline.
- Sprints are also helpful for 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 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.
- Projects on the roadmap help communicate, at a high level, the progress for all of the 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.