Your project’s backlog is one of your most valuable assets on a project. It’s where the business requirements meet the technical implementation. It’s everyone’s main hub for information, and it should be a lot more than a giant to-do list. That’s why it’s important to structure your backlog to set your team up for success in the long term. Here are five questions that your backlog should be configured to answer.
1. Are we on track to complete the project on time?
This is the single most important question your backlog should answer. If your team is not on track, it’s important to know that as early as possible. It allows you and the product owner to discuss changes to get back on track, like cutting scope or increasing the timeline.
There are several things your backlog will need in order to answer this question. In order to track progress, you’ll need to estimate your stories in term of effort. You’ll need to use this effort estimation to track historical progress (velocity) and project future velocity in the form of a burn-up chart.
2. Are we on track to complete the epic/feature on time?
To create a milestone of deliverables, you will have gone through some sort of initial estimation of the features your team is hoping to deliver. Although those estimates will be wrong, they shouldn’t be tossed aside. They can be a great tool to help you create a strong backlog. Tracking against those estimates will help you uncover the gaps in your initial estimates and the real effort. It can help the product owner make detailed feature scope decisions. Lastly, it will be great information for you to have for future epics.
In Jira, I like to use the “Parent Feature” tool to track this work. I create an initial “budget” story that represents the estimated effort in terms of points. As new work is estimated against that feature, I reduce the points left in the bucket. Additionally, I add functional stories, which will become much more detailed stories before they are estimated. The combination of functional stories, estimated stories, and budget points left provide enough metrics to determine if a feature is on track or behind.
3. What work is planned for the next few sprints?
Your backlog should include sketches for the next two to four sprints. This is important because it gives you and the product owner a quick glance at the highest priority work. If your team has multiple streams of work ongoing, it will help you see when work will be done.
In Jira, I accomplish this simply by adding two sprints that are not started. Then, I pull stories into those sprints as prioritization sessions with the product owner happen.
4. What is the status of the work in the current sprint?
Having visibility into the status of current work in your backlog is valuable in multiple ways. It can help you keep work in progress (WIP) down by making it visible. It can help you escalate work that is blocked. As work is moved through in the sprint, having visibility into the status will help give you a gut feel on whether all of the planned work will finish within a sprint. Lastly, it can give you insight on whether developers might finish their planned work early and need additional work.
I accomplish this in Jira by using the Sprint Swimlane feature. There are columns for each of the statuses that our team has normed on: To Do, In Progress, In Review, Blocked, and Done. Developers move the work through as the sprint progresses. You’ll have to make sure developers understand all of the benefits I outlined above and how those values are great for the project’s success, otherwise it’s easy for your swimlanes to get out of date.
5. What work needs attention in order to be implemented?
Your backlog should be the main hub of information for your project. That means while your backlog tracks developer tasks, it should also help other team members create work lists. When your backlog is structured in a way that a designer could quickly see all stories that need design input or a business team member could see all stories that have open business requirements questions, it’s a game changer.
In Jira, I accomplish this using labels. You have to be careful with labels, because they are so freeform. So, our team has a Jira best practices doc that outlines all of the labels our team has normed around and what they mean. We have the following labels:
- open-question: Needs attention from product team before it can be estimated
- needs-design: Needs design input
- tech-ref: Ready to be estimated, but not yet estimated
- ready: Ready to be pulled into a sprint
Additionally, I have quick filters configured to allow team members to filter the work down to see things they might care about (such as all need-design stories).
Considering these five questions when you are creating your next backlog can help you set your team up for success early. What other questions should our backlogs answer for us?