Before diving into project planning, product backlog management, Issue grooming, or any form of work planning we always recommend that teams have a shared understanding of Issue types and priority for Issues across the team. If this isn't something you yet have, continue your project rituals, but plan in time to practice some of the tips below.
Start by reviewing what Issue types you work with
Most teams have habitual types of Issues that get created, for example: bugs, feature requests, tech debt, user stories, etc.
To streamline continuous grooming of Issues, we recommend documenting common issues that you create. This helps standardize the info you look at, by Issue type, when refining those Issues. In addition, discuss how you determine priority for each of these Issue types. What does low, medium, high mean?
Ensure the priority buckets (however, you define them) have a shared team meaning. Is there a criteria you can use for each level of priority? For example: High priority is only used when a customer is blocked from using the product or there is X amount of business revenue affected.
The more concrete a criteria for defining priority and needed info per Issue type, the easier it will be to distribute planning of projects and prioritize work that needs to be done without conflict of what needs to be worked on, in what priority.
Use Issue templates for common Issue types
Once you have your Issue types documented, use GitHub’s multi-templates so the team can ensure relevant information never gets missed when creating Issues in real-time.
It's easy when creating new Issues to forget to add info. With a template, regardless of who creates project Issues, the team has a shared understanding of important details that complete the Issue.
This is also helpful to save hours against project interruptions. For bugs, a template ensures effective info gathering and standardization for potential sprint interruptions. Robust bug reports ensure interruptions are effectively prioritized based on a robust suite of data.
Running effective product backlog refinement meetings
While every software team operates effectively based on their own workflow, rhythm, size, and practiced project management philosophy, we share a few tips we've heard from teams on what works for their refinement sessions:
- Have product backlog refinement meetings (typically 1-2 hours) on opposite weeks of sprint planning. This breaks up long meetings and gives product/stakeholders buffer time to answer questions about upcoming work before it gets accepted into a Sprint if something about a project is still unclear.
- Have the entire development squad in attendance. Anyone who is going to be working on the project work or issues being discussed should attend. You should also have the Product owner / Design owner attend. Product and Design walkthrough the Issues in the product backlog and help answer questions as things get discussed.
- Things to cover in the meeting: Spend the meeting reviewing upcoming pieces of work, breaking Issues down from large stories to development tasks, discussing if the top of the backlog is still prioritized effectively, as well as estimating new pieces of work.
- End by reviewing if the placement of Issues in your backlog pipeline is still relevant. 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.
Keep the top 20% of your backlog pipeline prioritized in ZenHub
In ZenHub, we recommend the following rule of thumb for best organizing your product backlog in a Workspace: everything in the top half of your backlog should be prioritized starting with the most important upcoming Issue on the top. Everything at the top should be spec ready, have clear acceptance criteria, and be estimated.
Everything that is considered a priority, or in the top 20% of your backlog should also have an estimate. If your estimate is large on any of the Issues in your top 20%, consider breaking down this work into smaller stories and tasks in your next product backlog refinement session.
Separate your Product Backlog from your Sprint Backlog
By separating the backlog from the Sprint backlog, we notice teams communicate the priority of work more effectively. You’re able to split up:
Work that is sprint-ready, but not yet accepted and planned into the upcoming Milestone (Development backlog)
And work that has been committed to, and accepted into the upcoming Sprint (Sprint backlog)
Want to learn more about product backlogs? Check out this article about the importance of a product backlog.