Is the Backlog an Unnecessary Proxy?
High Priority Mail
Last week a letter reached me that had the announcement IMPORTANT DOCUMENTS on the envelope. When I eagerly tore open the letter, awaiting some life-changing documents inside, it turned out they were not. It is a common pattern: You all receive e-mails stating URGENT in the subject, but they’re not. And how many e-mails are flagged “!” important — but they’re not? When I judge the importance of a communication to me, its outward appearance is not the only thing I take into consideration, it is also very much the sender that counts. If I know the author to be trustworthy, based on my previous experiences with her, I tend to treat those messages as much more relevant than messages from an insurance company (that usually wants to sell more insurances) or from a business I never dealt with before.
An Intermediate Artifact
This thought crossed my mind when at the #lkce13, “the” David https://twitter.com/lkuceo stated that a prioritized backlog introduces an unnecessary proxy variable. Agreed, stakeholders and dev team are better off talking to each other instead of capturing conversations in an artifact with only the product owner talking to each of the sides. Also, a backlog may imply a commitment to a path, when in fact it might just show alternate future directions in which the product may involve.
Backlog for Focus
On the other hand, if you have n stakeholders and m developers, and every developer is to talk directly to every customer, you will have n * m conversations taking place. When the product owner acts as information hub, only n + m conversations take place, which might be the only feasible way.
Also, the product owner is supposed to act as the business value expert, condensing the multiple voices of the stakeholders, and even opening up new options. It makes sense to me to have a domain expert drive this and not spread accountability for priorities all over the team.
The third and final point brings me back to the story about the “important” letter: it is about trust. When the dev team trusts the product owner enough to make good decisions on priority, there is less urgency to discuss priorities directly with stakeholders. Maybe the PO has shown good judgment in the past. Or the decision process is transparent enough, showing that all relevant stakeholders are involved, that all sides have been taken into consideration. If you do not trust your product owner to make good priority decisions, you might need to ask why, and address that issue.
Trust the Product Owner
The backlog is not to be used as a contract artifact on paper, inhibiting face-to-face conversation and feedback loops. There is a balance to strike: The team needs to alternate between an opening, questioning stance involving all stakeholders, and a focusing, deciding stance where the product owner is responsible to narrow down all possibilities to a manageable number. The product owner is supposed to lead by reducing uncertainty about the future, providing clarity for the team. She can achieve this task better when all parties trust her decisions, based on her openness, her focus, and her commitment to the job. A prioritized backlog is a tool to achieve this, but it is abused when just used for written “THIS IS IMPORTANT” statements.
So, watch out for backlogs that are used to hide information like value, options, or risk, inhibiting collaboration. Make your backlog a dual-use tool both to start conversations and to provide focus.