As you work through your first release, here's a few common questions, best practices, and handy solutions.
I have non-estimated issues in my release, how does this affect the report?
All non-estimated issues will automatically be assigned an average estimation, as long as at least one issue in the report is estimated. The average estimate assigned to not yet estimated issues is calculated by adding all the estimates on the release and dividing it by the number of estimated issues in the release (open and closed). number of issues in the release / total number of estimated issues
What's the difference between an epic and a release? When should I use each?
Zenhub Epics are a theme of work that contain subtasks required to complete the larger goal. Epics contain issues related in subject, and the scope is flexible. Issues can be added or removed as teams discover more about the project or larger story being completed. Epics are a great way to visualize in list format how a grouping of tasks are progressing across your workflow.
Whereas releases can be considered as much larger objectives, goals, or projects being worked on that span multiple sprints, perhaps across multiple teams, and touch multiple areas of work. Tracking your Q2 goals? Use a release. Have a major feature launch that contains 5 or 6 large user stories (which are broken down by epics, with individual tasks to complete these stories in issues)? A great time to create a release!
Overall, epics help you visualize how groupings of stories and tasks come together, while releases help you work towards a major goal across a much larger set of work.
There is also a significant difference between tracking progress of tasks in epics and the progress of a major release. The progress of work assigned to epics can be tracked issue-by-issue in the Board (teams can see all the issue cards in one central view, including where in the workflow each issues is). Releases, on the other hand, are more high-level, such as when tracking individual issues would otherwise be too much (such as spanning multiple sprints).
When should I use a sprint vs. a release to track work and progress?
The concept of sprints is to help teams plan short iterations and organize issues against a single deadline. Zenhub Releases, on the other hand, should be used for long-term business goals, external commitments, or any project work that spans across multiple sprints. Releases also have a single end-date, but allow for grouping of multiple Issues, across various smaller deadlines.
When used together, sprints help teams keep an eye on short-term deliverables and scope related to immediate commitments, while releases help teams get an understanding of how short-term work paired with long-term commitments that have not yet come into scope come together around predicted end dates.
For example, you may have external commitment with a fixed date to deliver a product. If your deadline is the end of Q3, but it is currently only the start of the quarter, your team will have multiple deliverables and sprints within the quarter. As you plan your weekly commitments, leverage automated sprints to organize work being worked on versus that which is still in the backlog for a future iteration. Leverage a release report to start organizing all issues related to the external deliverable of your product, even if it is not yet being worked on to get insights into whether your team is burning-up towards your desired launch date as you iterate within your sprints.
What's the difference between GitHub's Releases and Zenhub's release reports?
GitHub's Releases tab is a central location for teams to package and provide software deployments and release notes for users that leverage their products. Zenhub releases, on the other-hand, are a powerful reporting tool that allows organizations to track against long-term goals or deliverables across: multiple deployments, teams, repos, and sprints irrespective to code or where issues live within the GitHub environment of the team's organization.
Being an internal team report, they help teams predict project end dates based on scope of work and historical velocity, add burn-up reporting for project managers looking to track work across multiple sprints and teams, and provide everyone on the team a central location to visualize roadblocks and team progress.
What's a good time frame for a release?
The start and desired end dates for releases should be discussed with your team! In general, here are a few questions to ask yourself as you plan for your first release: “How will our work come together for this major feature launch at the end of the quarter?” “Do we have work that we know will span multiple sprints?” “Is there a major project we are planning for?”
As you start to visualize your backlog of work, the answer to how long a release should be becomes much clearer.