Managing a Product Backlog when there is only one development team in an organization creating one solution at a time is relatively straight forward. However, large enterprises have multiple development teams creating a multitude of solutions with interdependencies between them. Managing product backlogs in these situations becomes very tricky, especially when it comes to prioritizing features being developed by one team but being consumed by another team or multiple teams.
Most Sprint teams are typically organized around a Product (for example, Loan Originations Platform) or a Capability (for example, Customer Data for the Enterprise). Product teams will typically consume features developed by the Capability teams and incorporate it into their final solution. Consider a simple example, where the Customer team that owns the customer data of the company is enhancing the search capabilities they make available to their users. They will typically define different types of searches and put them into a product backlog from where their development teams pick them up. If there is only one Product team consuming their output, then prioritizing the backlog is a simple exercise. They will ask the Product team to prioritize the searches and take up development according to their needs.
The problem becomes a lot more complex when there are multiple Product teams who all consume the search services being created by the Customer team. Now we have a situation where we have competing priorities. The Customer team has multiple search types that are requested, all of whom have roughly the same level of importance. The Product Owner of the Customer team has a dilemma – which of the requested searches should go into the next Sprint and which ones get relegated to later Sprints?
One way of doing this is to randomly prioritize the requested searches one after the other and see if anyone screams. If there is no reaction, then go right on ahead. In actuality, no noise at the beginning is not a guarantee that there are no problems. Her team could be half way through a Sprint before the reprioritization is noticed and suddenly there is a major crisis with people demanding explanations as to why their searches were given lower priority when they stressed how important the capability was to their users. The reality is that there is no good excuse other than no one screamed when the searches were first reprioritized by the Product Owner.
A better way of prioritization is based on the business value delivered to each Product team by the capability being delivered. The Product Owner should ask for a quantified business value in terms of either potential increase in revenue or reduction in cost to the requesting teams from the capability they are asking to be built. Armed with this information, prioritization becomes a relatively straight forward exercise for the Product Owner. The capability that results in the biggest business benefit to the organization goes first and so on, down the line.
By being open and up front about this, there are no surprises to the requesting teams. The relative business value to the organization provided by each team can be shared and debated before the product backlog is prioritized. If there are any disagreements about the relative values submitted by the teams, they can be discussed in an open forum with requests for justification by any other team that feels someone may be padding the numbers. But once this exercise is done, everyone understands where they stand in the grander scheme of things – what makes sense for the business as a whole, not just their own piece of it.
The Product Owner can revisit this periodically, to ensure that nothing has changed, that will cause the numbers provided to her to have shifted around. If she gets new requests for capability that are higher value to the organization than what is already in their backlog, she can easily alert the impacted teams to let them know they are being superseded by a higher priority request.
In general, I believe it to be good practice to stack rank all features on the basis of value and develop them accordingly. There is always going to be foundational work that development teams do outside of specific features or capabilities they are building. These will not be impacted by stack ranking features on the basis of value. Once the consumers of the capabilities understand the rationale behind the prioritization of features taken up for development, they are more likely to trust the process. It does not mean they will be happy when the Product Owner pushes out a feature requested by them to a later Sprint. They will know it was not done arbitrarily or on wing and a prayer by the Product Owner, but purely on the basis of relative value to the business as a whole.
