Learn tips and best practices below to manage Epics and track blockers within your Sprint to cut down on meetings.
Create two new pipelines to manage Epic movement
- Creating two pipelines helps organize 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.
Use nested Epics to track large scope projects
When you nest Epics, teams get a complete understanding of the intricate nature of how work intertwines. Developers understand how a small user story rolls up into a larger piece of work; while Project and Product Managers can track overall progress, visualize where in the workflow work is, and spur conversations around blockers, or potential roadblocks that might be impeding progress.
Use dependencies to track blockers within Sprints
ZenHub Dependencies help teams get better end-to-end visibility for Issues and stories when moving projects forward. This information give teams a stronger understanding about why a block is occurring and what is needed to move initiatives forward with less risk.
In a Sprint, you should have a prioritized Sprint Backlog, but there might be work within the backlog that is dependent on work already in progress.
Once dependencies are created, you can filter blocked and blocking relationships using filters through the icons located on the top right of an Issue card to easily understand what should be worked on next.
Creating dependency relationship can help cut back on meetings, relay critical information for remote team members, and is a great way to understand the relationship between work to speed up software cycles. Project and Product managers can also easily see where they need to unblock teams.
Commonly asked questions
Can I use Dependencies on the Boards with no milestones, releases and story points?
You can absolutely use Dependencies without other functionality for reporting in ZenHub! There’s no obligation to use estimates, releases, or reports. We encourage it to help your team get more predictable with software cycles, but you can certainly get started with just the Board!
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.
- 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
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.
Do Issues have to live in only one Release?
Nope! You can have an Issue in more than one Release. We recommend adding notes in the Issue about the impact it will have on both Releases to keep up team communication.You can learn more about Releases here.
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
- 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.