A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements.
Product backlog is sourced from the product roadmap. I have already blogged about product roadmap earlier. Please read that blog to get a better understanding on how product roadmaps tie to your product milestone and release success.
A backlog is a prioritized list of requirements and the dev team uses this list for their next sprint cycle. The role of a Product Manager is to create priority for the requirements. The product manager along with the scrum master also organizes a sprint planning session where a list of requirements is pulled from the backlog into the current development and release cycle. The job of a PM is to delicately balance the priority of the items that get into the next release cycle.
It’s the role of the product manager to ensure that the backlog is well prioritized so that the release process becomes very easy. A backlog also is important to set expectations with stakeholders and development teams. PM should use the product roadmap to tie the feature and backlog priority to the release and product expectations. The backlog and roadmap combined can also be used as an effective tool to present the status of the product to executives and stakeholders. and getting alignment from all.
A product backlog contains both stories and Epics. Epics are long complex stories that need to be broken down into several stories and requirements for development. Epic might take more than one product sprint release to complete all the features.
Sourcing the backlog through a tool like Jira or Trello makes it easier to tie the backlog to the sprint cycle and the release cycle. The tools will also provide a one-stop-shop for the product backlog to be seen by all the stakeholders and the developers. In case there are any questions about the priorities, the product manager should use the product backlog to align expectations. PM should also use the tools to assign the right stories to the developers based on their skill level.
Sometimes a product backlog becomes a critical tool to stave off aggressive stakeholders.
The biggest issue for product managers is saying NO and pushing back. There are several situations where the stakeholders are very pushy and they want a particular feature to get higher priority in the backlog. For example Sales, VP Karen might say we will lose millions on the sales lead if you don’t put this feature. Marketing VP Bob might say you don’t understand I just got off a sales call with the big customer and they want is just one thing to purchase. Unfortunately, they don’t have many more details to add or they’re just going over your head to get more visibility. There might be another stakeholder who might say that they want a customizable color for the background which doesn’t have any relation to the product features or customer priority.
The product manager should use the backlog and roadmap to explain their NO to the aggressive stakeholders. Let them know that their feedback is valued but their feature is not getting the higher priority since that does not fit the roadmap. In some cases just letting them know that their feedback is valued and pushing their request to backlog would suffice. In other aggressive cases, a stakeholder meeting would be necessary to align priorities.
As a good PM, you are responsible to manage the pushy and stubborn stakeholders who will not take no for an answer. They might be the experts in their respective domain but when it comes to the product you are the expert. You are responsible for accessing and prioritizing the backlog, based on the short term and long term needs that actually serve the purpose of the product and targets the market.
Assigning priority to the backlog items and also evaluating priority every sprint cycle is a critical task that a product manager should do to ensure that the backlog is current, updated, and prioritized. You have to assign scores for each backlog item to ensure that the right backlog items are added to the next development cycle.
Backlog grooming sessions should be run by the product managers typically at least once every sprint. I usually invite a few decision-making stakeholders such as the sales manager, the engineering lead, and the marketing lead to these meetings.
A good rule of thumb is to try and aim to be at least 2 to 3 sprints ahead of your team. If you are a new product manager then the backlog grooming should be prioritized. You have to block your calendar to get your backlog sufficiently groomed within 2 to 3 sprints. It’s critical to do this since this is the only way to stay ahead of the demand of the stakeholders and the features dedicated to the product.
If you’re going to show your backlog the love it deserves, you’ll need the tools to help you do it. Here’s a selection of tools to help you groom your backlog.
Jira – One of the most popular tools for managing your overall engineering backlog.
Pivotal Tracker – Another popular tool that’s used for maintaining your engineering backlog. It’s more pleasant to use in Jira in places but can be a little tricky to distinguish between the backlog and the current sprint.
Trello – Perfect for gathering input from stakeholders in your business/discovery backlog.
Once your backlog is groomed, you can go and add further details to the stories, if needed. You should also follow up with the owner or the requester of the particular backlog item to get more details and feature completeness. It’s critical to have a complete user story so that there is no confusion or pending items when the issue is pulled from the backlog into a development sprint cycle.
In many instances, there is a significant time gap between the filing of user requirements to the backlog and when the story is pulled for development. Meanwhile, if there are missing requirements in the story then its hard to retrieve the details especially if the store owner does not remember or have the missing details. Hence backlog grooming is critical.
Remember that product management and building products never stop. This means that your backlog never stops. It’s your primary responsibility, as a PM to manage backlog for the success of your product.