Groans. Eye rolling. Heavy sighs. Do you ever get these kinds of reactions when you mention the product backlog? Is it a topic that doesn’t seem to inspire excitement among your stakeholders and engineers? If so, perhaps it’s a matter of perspective and you can turn things around with a new outlook.
The product backlog can sometimes have a bad rap as something that’s essentially just a record-keeping tool. It’s not really the stuff developers dream of or what makes stakeholders’ eyes light up when they envision creating a new product.
But the product backlog is a powerhouse tool – one that actually carries a heavy load within the Agile development framework. And if you take the necessary steps to build a good one and refine it properly, there are all kinds of benefits, both for the engineers working to build the product and the stakeholders who have business concerns. It’s these benefits that bring to light and remind us all of the fundamental importance of the product backlog, and why it’s necessary to give this sometimes-overlooked aspect of Agile development the attention it deserves. Here’s what you need to know about the product backlog, so you can maximize the value of your product.
“Finding common ground among people who might have vastly different viewpoints and who therefore have vastly different objectives is never an easy task.”
1. The product backlog should be built cemented by solid agreement between engineers and stakeholders
The starting point of the Agile delivery cycle begins with a good product backlog. It’s a wishlist, covering everything from new features that could be built out for users to the technology upgrades you might need to deploy to the fixes you intend to make to the improvements someone wants to make on the existing application. It’s a diverse set of needs and wants brought to the table by a diverse set of participants who represent both the business and the development sides of the fence, and is product owner duty to prioritize all these needs according to business value.
But let’s not think in terms of barriers. Business needs brought to the table by stakeholders and development concerns brought to the table by the engineers don’t necessarily have to be in conflict with one another. There’s an art to creating agreement, and it starts with creating a product backlog rooted in agreement.
So let’s call everyone a stakeholder, shall we? The product backlog (PB) should be built by the Product Owner, brick by brick, with all of the stakeholders involved, working together to not only build it but also maintain it. It is, after all, emergent. New items will be added and the backlog will need to be regularly reviewed and prioritized to maintain the alignment between what development team has already implemented and new business needs.
Alignment and prioritization are the key, since the product backlog is the foundation of the product development cycle. It’s where the team’s work is clearly laid out for all to see and it reflects all of the current priorities, which are based on a mutually-agreed upon set of needs.
2. Focus on metrics to track your product success
Keep in mind that the product backlog is dynamic and improvements will (and should) keep rolling in throughout the development cycle. But well, how will we define the changes that really matter to make? This era is becoming more data-driven than ever, and Product Backlog decisions we might face must be taken under the light of statistics, analytics, and KPIs. Even when Product management intuition is still a great thing to develop, we must be focused on data.
3. Promote and support the role of the Business Analyst
As any politician: coalition-building is tough stuff. Finding common ground among people who might have vastly different viewpoints and who therefore have vastly different objectives is never an easy task. And when different groups come from different worlds – the business world and the developer’s world – where each has their own terminology, that makes the mountain they all have to climb even higher.
Obstacles, obstacles, obstacles. The Business Analyst (BA) is there to remove those obstacles, and help everyone arrive at common ground sooner rather than later.
“Product Backlog decisions we might face must be taken under the light of statistics, analytics, and KPIs.”
How do they do it? The Business Analyst is well-schooled in both worlds – business and development – and understands the needs of the stakeholders as well as the needs of the development team. BA’s are trained to look at all the needs, understand the conflicts that can arise, and map out a way to prioritize tasks in a way that takes all needs into consideration so both sides are satisfied (or at least satisfied enough to move forward, since you can’t satisfy everyone all of the time).
One of the most important things the BA does is to make choices. Sometimes they have to say no to certain stakeholders, or figure out how to prioritize the stakeholders. Some are more important, after all, than others. Many of them have low interest in the product and perhaps when it comes time to divide your time among the different stakeholders, you may need to think proactively about spending more time with some and less time with others. In general, your most important stakeholders are your product users and/or the customer. The BA makes it a point to get to know the interests of these important stakeholders, and keep themon top of their mind when they’re prioritizing tasks.
They’ll want to hold regular refinements sessions, too, and update all the stakeholders on recent changes and/or re-prioritization: transparency is so key! Stakeholders should know about these things as well:
- Whether testing criteria have changed
- If any user stories have changed
- If any new priorities have been added
- If any new user stories have been added
- If any new features have been added
- If any estimates need to be adjusted
But knowing all this, it’s still important to remember that when tasks are prioritized, it’s according to business value. Hence, the role of the Business Analyst becomes crystal clear here: to continually analyze the backlog to ensure that business interests are driving the team’s work, not some low-priority interests like “cool features” or improvements that users don’t really need.
Wrap-Up
So, what’s the final word here? Product backlogs are like living organisms:
- They grow
- They change
- They must be managed (but they are difficult to manage)
- They must be pruned
- They can become overwhelmed, or suffer from TMI (too much information or too many suggestions from users)
- They receive input from a diverse set of people but must remain focused
No matter what kind of product you’re developing, taking good care of your product backlog is a key part of good management. Business Analysts can follow best practices when managing the PB with good communication skills, staying focused on business needs, staying organized with the right tools, and constant diligence to the process.
Organizations that work on their product backlogs this way can expect a more efficient process, ensuring the team’s success by helping them avoid work that hasn’t been well-defined and which may not end up being necessary at all. And with all of these ingredients in place, who knows, handling the product backlog might become an enjoyable experience!