Ar·ti·fact | ˈär-ti-ˌfakt; Something or someone arising from or associated with an earlier time, especially when regarded as no longer appropriate, relevant, or important (Merriam-Webster).
Fortunately, the Product Backlog lacks the self-awareness to find this offensive. Despite being categorized as an Artifact, the Product Backlog is highly relevant and important when it comes to Agile Enterprise Software delivery initiatives.
So, why is the design intent for the Product Backlog Artifact design to shape the future Vision of a product or experience? This particular Artifact is not like others, it is alive. This is a necessary disclaimer that Agile Teams and organizations must understand to avoid undue confusion.
An example of a common Product Backlog pitfall:
A key Stakeholder attends a Sprint Review to view a demo of the latest Increment of the Product. The Stakeholder proposes an enhancement to a particular Feature of the Product. The Product Owner acknowledges the proposal. They agree there is value in the enhancement. Further, they define the enhancement as a User Story placed in the Product Backlog. Nearing the next Major Release, the Stakeholder had another Sprint Review. This was only to find that they did not include they requested enhancement Product Increment.
Disappointment ensues.
Avoiding common Product Backlog pitfalls:
Just because a User Story exists in the Product Backlog, does not necessarily mean that they will implement it in the next Release. This is because of priorities that compete, dependencies, and constraints that all Stakeholders may not be aware of. The Product Owner is responsible for optimizing the ROI for each Release. If other Product Backlog Items deliver greater value, there must be a decision to prioritize elsewhere.
One of the more challenging aspects of the Product Owner role is to help Stakeholders understand where their interests stack up against other Work Items in scope. And, whether they meet the necessary criteria to qualify the active Release.
Continuous review of the Product Backlog with Stakeholders can aid in the management of expectations. They can prompt further discussion if the impact or value proposition is unclear to the Product Owner. With proper business justification, the Product Owner has the necessary authority to modify the Release plan to accommodate the request.
In conclusion:
As time progresses, and discovery continues, the Product Vision is likely to evolve, expanding the overall Product Backlog.
The Product Owner will continue to prioritize the Product Backlog Items within the Product Backlog. They base this on; ROI / Value to be realized. It is further based on the established Velocity of the Team.
The Product Backlog is a place for all great ideas. Especially those that could potentially add value. So, if you are a Stakeholder, know that if your Product Backlog Item is in the Product Backlog, it might get done. If it is not in the Product Backlog, it will not get done. Agile Teams are lean. They aim to minimize overproduction waste. Therefore, they typically focus solely on defined Product Backlog Items that the Product Owner has authorized. Prepare to share your feedback with each Sprint Review. Additionally, ensure the Product Owner understands the associated value proposition.
Subsections of the Product Backlog will isolate in Release / PI Planning events for longer-term planning. The plans, however, should not be concrete. Ongoing planning events will keep stakeholders informed of what is, and is not, in scope for a particular Sprint or Release.
At Mindset, our objective is to deliver amazing products. And, further, amazing experiences for our Partners and the End Users they serve. To maximize our likelihood of success, we spend a lot of time working with our Partners, Product Owners, and Teams to harness the full capacity of the Product Backlog. Even if it is what we consider an Agile Artifact.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
