Important: ZenHub sprints are a ZenHub entity separate from GitHub milestones
Changes made to GitHub milestones will not be synchronized with sprints. GitHub milestones will still exist however we recommend checking out sprints as they function similar to milestones with a few added benefits.
What are ZenHub sprints?
In Agile-Scrum, sprints are a fixed length of time (typically two weeks) during which an agreed-upon chunk of work is completed and ready to be shipped. ZenHub sprints allow teams to group issues together that will be completed within this timeframe. With ZenHub sprints, teams can build automatic, scheduled sprints that will create and close by themselves. Sprints are created at the Workspace level.
|Key differences between milestones and sprints|
|GitHub milestones||ZenHub sprints|
|One issue can belong to one milestone only||One issue can live in multiple sprints|
|Milestones are native to GitHub||Sprints are native to ZenHub and are not tied to GitHub|
|Milestones are created and closed manually for each sprint. You manually move incomplete issues to the next Sprint.||New sprints are created automatically when others close. You have the option to automatically move incomplete issues to the next sprint|
Setting up sprints in ZenHub
To set up ZenHub sprints for your team, select Create... on the sidebar or the green + icon located in the top right corner of your Workspace then select Set up sprints for your team
This will open the sprint creation modal which allows you to:
1. Choose the start and end date for your first sprint using the calendar. When selecting a start and end date for your current sprint, ZenHub will also automatically create two future sprints. You will see how often it cycles along with the written dates for all known sprints:
Note: To ensure your sprints run consecutively without any gaps, make sure your start date is ahead of your end date. Example: To set up a one-week sprint schedule that starts on a Tuesday, set your start date as Tuesday and end date as Monday:
When the current sprint closes, the next sprint becomes the current sprint and a new sprint is added after the furthest sprint.
2. Move unfinished issues to the next sprint: By toggling this option on, when a sprint completes (passes its end-date), all issues assigned to the sprint that have not yet been closed will automatically move to the next Sprint. With ZenHub Sprints, issues can live in multiple sprints. When unfinished or incomplete issues move from your past sprint to the new current sprint, the issues will continue to exist in the sprint they are being moved from (i.e these issues will belong to two sprints)
3. Automatically build new sprints from the backlog: By toggling this option on, ZenHub will automatically build your sprints. A suggested average velocity from your previous sprints will be displayed. You can adjust the number of story points you'd like added to your next sprint and the pipeline you'd like issues added from. ZenHub will automatically add issues from the top of this pipeline to your sprint.
Tip: We'd recommend running backlog refinement meetings to ensure your backlog is in order. Your backlog should be prioritized with the most important issues at the top. These issues should have clear acceptance criteria and be estimated. Learn more here
Issues that are not already estimated, will be counted with the value of 2 Story Points when being added into the sprint from your backlog pipeline.
Changing the sprint schedule
To change the sprint duration and schedule, select the green + icon located in the top right of your Workspace and select Modify recurring sprints.
Above the calendar, you'll see the option Change sprint schedule From here you can select your new dates:
Adding issues to your sprint
To add issues to your sprint, head to your ZenHub board. From here, you will be able to use multi-action or a combination of filtering and multi-action to add the desired issues to your sprint. This is a great way to eliminate the onerous process of performing certain actions over and over again.
For example, your team may dedicate a sprint to tackling bugs. The team can filter the Board by the bug label, select all issues, and choose the option Set sprint.
When viewing issue cards on the Board, you can see the sprint your issues belong to as they have a lightning strike icon next to the sprint name:
Filtering by sprint
When viewing your Board, you can filter by sprint to only view the issues that have been added to your ZenHub sprints:
Does your team like to follow a specific naming convention for sprints? Within ZenHub you can edit the names of your sprints. To rename sprints, select the green + icon located in the top right of your Workspace and select Modify recurring sprints From here, hover over the names of your upcoming sprints where you have the option to rename the sprints:
Burndown report: The Burndown report is split into 2 sections: sprints and milestones. Each page functions the same as the other except milestones will only show GitHub milestone data and sprints will only show ZenHub sprint data. Burndown charts break down your completed issues, open issues, and any incomplete issues within the sprint. Incomplete means that an issue was completed out of scope of the sprint or milestone. So an issue completed after the end date.
Velocity report: The Velocity report continues to function the same as it does today—with milestones and sprints side-by-side—with one small change. Milestones will still be shown per repo while sprints are per Workspace so they will always show their total value, disregarding the repo filter.
Since sprints are ZenHub data, Burndown charts and the Velocity report will load up to 15x faster