Create an Icebox, Development Backlog, and Sprint Backlog pipeline
By having these 3 separate Pipelines, we notice teams can communicate more effectively. You’re able to split up:
- Work that isn’t being worked on within the next 6 months (Icebox)
- Work that is sprint-ready, but not yet accepted and planned into the upcoming Sprint (Development Backlog)
- And work that has been committed to, and accepted into the upcoming Sprint (Sprint Backlog)
Issues in the Icebox help give the team clarity on agreed-upon low-priority items that aren’t worth closing, but just are not in your upcoming planned work. It’s also helpful to prevent the re-opening of Issues that were once de-prioritized!
The Development Backlog should be prioritized top-to-bottom by importance. Everything at the top should be spec ready, have clear acceptance criteria, and be estimated. We recommend having bi-weekly backlog grooming sessions to keep these Issues fresh, check priority, and ensure work is estimated upfront. Keeping this Pipeline prioritized helps teams understand the most important issue to work on next should everything in the Sprint be finished ahead of time!
Your Sprint Backlog should also be prioritized. This helps the entire team know the most important work that you’ve committed to accomplishing first in the Sprint. This might be a high-priority bug or a backend issue that is blocking front-end work. Note, when using Zenub Sprints, Issues that are not already estimated will be counted with the value of 2 Story Points when being automatically added into the Sprint from your Backlog Pipeline.
Don't add Epics to Sprints
Only accept Issues and smaller pieces of work 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. 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.
When reading the Burndown chart, you want to be below the grey ‘ideal’ line
Below we have some tips on when to check in on it, and how to get back on track if you notice you’re above the ideal line.
Having your Burndown in a central, visual location helps the team constantly check on Sprint progress. If you don’t have a central screen, we recommend looking at your Sprint at least 3 to 4 times during the Sprint to check on progress. Another option is to pull it up on a screen during standup and review it with the team. In the example below, the team isn’t burning down at the ideal Velocity needed to complete all committed story points before the 31st.
Checking mid-Sprint allows the team to converse on potential blockers, whether there was scope creep or surprises that came up once work started that created complexity, or if there were interruptions to the Sprint that caused unexpected work. The Burndown will visualize all Issues completed during a Sprint along with any that were completed out of scope (after the end of the Sprint).
Learn more about Burndown charts
Bumping an Issue sprint-to-sprint
Note: We recommend using Zenhub Sprints to automatically move incomplete work to the next Sprint. Learn more here
If you hit the end of the Sprint and need to move Issues sprint-to-sprint, before re-assigning a new Milestone, re-assess priority and estimation of the Issue you’re moving over.
Be sure to ask:
- Did something creep up that made this issue too complex to get completed within the Sprint?
- Is this still a priority against the other Backlog items?
- Is the estimate on this Issue still accurate?
Any incomplete Issues, meaning, Issues closed outside of the start/end time of the Sprint or Milestone, will be shown alongside the open/closed issues on the Burndown Chart.
We recommend using a way to nominate Issues that need to be re-discussed as part of your retro and planning process. Using a Sprint Candidate Milestone that does not have a deadline is a great start to a nomination process. Whether it’s work from a previous Sprint, important bugs, or technical debt, this process gives everyone in the team a way to raise their hand to speak about important issues and be part of the prioritization conversation.
Use labels to assess where time is being spent in a Sprint
Zenhub reports can be filtered by a label to help teams understand what type of work is being accepted into the Sprint and where the team is historically spending time.
You may want to use an “Interruption” label, for example, to assess how many interruptions mid-Sprint come up. We also recommend using the "bug" label to track how much time is spent fixing previous code. Over time, if you start to notice that more and more bugs are being worked on, you might want to have a team huddle to focus on how you can improve your QA or testing process.
Use the Web App multi-repo Milestones page
If you've created a multi-repo task Board, Zenhub makes it easy to create a GitHub Milestone spanning several repositories. This eliminates the need to duplicate work or sync Milestones together. If you need to track cross-repo work it also helps ensure that the start and end date, and title cross-repo are all the same to power cross-repo reporting!
If you need to make any edits to your GitHub Milestones, using the Milestone page also helps edit and close those Milestones in bulk. This helps teams save time having to dive into each repo in GitHub to otherwise close or edit Sprints.
Learn more about GitHub Milestones
Showcase your current Milestone on a central screen
Use the Milestone filter to bring up your current milestone. We recommend having this in an always visible location in your office to consistently keep ahead of your Sprint. You can use fullscreen mode to maximize space on your central screen!
Having it in a central location, and using it to facilitate daily standups or scrums helps you get into the habit of closing Issues on time (to keep your burndown updated!), help chat about potential blockers, and uncover any potential unknowns that weren’t originally discussed during estimation.
You can also layer filters on top of each other, such as the Assignee filter to pull up your own individual assigned Milestone work to get an even more focused view.
Everyone can further customize their Board and remove Issue card metadata using the Board options menu from the sidebar to customize what you see, and help get some real estate back:
Commonly asked questions
What’s the difference between tracking a Sprint using Zenhub Sprints and the purpose of a Release Report?
Zenhub Sprints help teams plan short iterations and organize issues against a single deadline. Sprints are also helpful for planning time-boxed efforts where there are 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 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 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.
What do we do if we have a different definition of ‘Done’ than 'Closed'?
Zenhub reports automatically use ‘Closed’ as Done, but you can use the burn pipelines on the Burndown chart to define a different definition of Done. This will take the time at which the Issue moved into that pipeline to report as ‘Done’ on the Burndown.
We often have a lot of issues closed at the end of the Sprint, making it hard to get value out of the Burndown. Can we track incremental progress towards Issues to avoid end-of-sprint closing sprees?
While the Burndown only captures closed Issues or the time at which an Issue moved into a particular pipeline, if you’re seeing a lot of closed Issues at the end of Sprint, and are constantly above the ideal line, here are a few best practices we recommend:
- Have a discussion about the size/scope of the Issues you’re accepting. Are they too big? Is there a better way to break down Issues?
- Do you have a central location to keep the Burndown or Board visible to the whole team? This can help with habit changes around keeping Issues updated and closed!
- Prioritize the lowest estimated Issues in the Sprint first to close quick wins before taking on more complex Issues.