What would you do if one of your teams reported it was unable to deliver upon a commitment because the tool being used was perceived as undermining the team's efficiency? As a Scrum Master, your first instinct is to address the perceived blocking issue. However, sometimes the solution is not as simple as it would appear.
I was recently part of a project team that was struggling to execute on project scope within the desired timeline and one of the loudest complaints was, “It’s the backlog.” In digging deeper, there were opportunities to improve the decomposition of the stories as well as to improve the availability of supporting materials to better enable the team to estimate work for the sprint. However, underlying these improvement opportunities were other, frankly, harder-to-solve challenges.
A product backlog is a useful and necessary tool for Agile teams. It is the written reflection of the desired product functionality, a roadmap for delivering value to the business in shippable increments, and a reflection of the team’s tasks and commitments to deliver on that value. It is a framework to be used like any other tool, but its value can be undermined by other issues:
ISSUE 1: Misunderstanding or lack of clear product strategy
A thousand user stories will still not solve a lack of cohesive, clearly-articulated product strategy. That is the bedrock upon which the product backlog should be built, as it provides a prioritization scheme and focus. It also remains a touchstone throughout the release for the team to measure its progression toward business goals. Without this, the backlog becomes a loose affiliation of capabilities with no context, which may or may not further the objectives of the organization.
A related issue is a misunderstanding of an existing product strategy. I have found this to be common with teams that do not have a strong onboarding model where newly-added resources are dropped into the mix without a solid understanding of the history of the product or project. What they manage to gather is incomplete and, at times, misinformed due to the lost context and tribal knowledge that exists with other, more tenured resources.
The bottom line is -- if everyone on the team cannot answer “Why are we here?” and “What problem are we trying to solve?” -- then it should be considered an issue that requires immediate resolution. The solution might be recurring strategy updates by the product owner, a team Wiki for resource onboarding, a solution like Aha! that helps visualize and centralize the strategy, or simply a 1:1 conversation between the product owner and any newly-added team members.
ISSUE 2: Expectation that product backlog starts as “The Complete Picture”
Gone are the days of 300-page requirements documents that took a year to write, only to find that the organization’s needs had changed in the interim. The idea that a product backlog must be a 100% complete, end-to-end reflection of the solution before work can begin is counter to Agile practices and even the Agile manifesto.
What teams need to focus on instead are:
- What is the strategic or business goal of our release, as informed by the product strategy?
- What constitutes the Minimal Viable Product (MVP) that meets that goal and are we aligned on that understanding of MVP?
- Each sprint, do we feel that our current work supports the MVP definition?
- Are we committing to anything that is outside of MVP, at the risk of not completing other higher-priority MVP work?
- Does the team have a minimum of work to stay busy for the next 2 – 3 sprints, while the product owner continues to develop the backlog?
- Has the team identified gaps in the backlog to deliver the MVP product, assigned responsibility for closing those gaps to a team member, and clearly articulated when those gaps must be closed to avoid blocking progress?
If the team is not able to answer these questions or is not aligned on the answers, then the very next step should be bringing them together to resolve gaps.
ISSUE 3: “Resolving backlog quality is not my problem.”
A product backlog is not the exclusive domain of the product owner. A team should feel empowered to help identify and author stories, correct or expand upon acceptance criteria that may be missing, add links between related or dependent stories, add supporting resource files, and help question prioritization of stories where concerns exist. The delivery team also has a fundamental responsibility to estimate the relative size of a story as well as define tasks, time estimates for those tasks, and indicate their progression through the sprint.
To be clear, I am not advocating for the Wild West. A lack of a change management will undermine product quality. However, that change management process does not need to be a rigid bureaucracy. The delivery team and the product owner(s) should have a frank discussion about how changes will be implemented in the backlog by multiple parties.
- What kind of change is or is not allowable by the team versus the product owner?
- When is change allowed?
- Who must review and approve changes?
- How does that person know that it is time to perform that review?
- How are we handling the prioritization of changes (new scope) in comparison to original scope?
Setting these expectations upfront allows the project to build a scalable process that is not dependent upon a limited resource to fulfill. Even teams that have multiple product owners, or a product owner with business analyst support resources, may find themselves with a capacity problem, particularly at the outset of building a new, complex solution. Productive teams have joint ownership for solving that issue, as well as developing a shared understanding of how that will work.
ISSUE 4: “It wasn’t written in the story, so we didn’t build it.”
There is often an over-reliance on upfront, written scope to replace communication with stakeholders and product owners. This is a more comfortable position for delivery teams as it places the burden on the product owner and assuages a fear of accountability if a product fails to meet expectations. It also smacks of failed waterfall mentality.
In answer to this complaint, Ron Jeffries provides the three C’s from Extreme Programming Installed: Card, Conversation, and Confirmation (Essential XP: Card, Conversation, Confirmation). Mike Cohn, of Mountain Goat Software, reiterates the importance of communication and states that a user story is “a promise to have a conversation” in his Better User Stories online video course. What these thought leaders are emphasizing are core tenants of the Agile Manifesto:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
I’ve yet to see a product backlog that contains acceptance criteria that cover every finite aspect of product scope. The reasons are legion and many are legitimate. So how do we solve for that? Start with an alignment within the team about:
- What is an acceptable level of detail within a story?
- Does the need for detail change as a product flows through its lifecycle?
- When does varying level of detail get added and by whom?
- How do we capture referential information, such as design specifications, if they are not written into acceptance criteria on the story?
- Is the product owner committed to honoring the spirit of those conversations when it comes time for assessing story acceptance? Here, we are talking about the product owner being accountable to not change the goalposts, so the team isn’t left feeling like it must pull the requirements bible out as proof that it delivered a “done” story.
- How do we ensure that we make space and reserve capacity for these conversations to take place among all the other demands of the iteration?
Answering these questions as well as those in the prior issues will help the team develop a strong, collective plan, where everyone is bought in to find solutions.
Developing high-quality software is hard. A product backlog is just one tool to enable a successful outcome. If you are hearing from your team that the tool isn’t as sharp as it needs to be, listen and inspect. You may find that teams complaining of the “backlog” may really be struggling with other issues of communication, resourcing, strategy alignment, or implementation processes.
projekt202 is the leader in experience-driven software strategy, design and development. We have a unique and established methodology for understanding people in context — we reveal unmet needs — which drives everything we do. This leads to a crisp, clear understanding of the customer, which shapes the design and development of new solutions and experiences. We have the expertise, teams, skills and scale to deliver sophisticated software solutions that improve any and all touchpoints across the user journey.
projekt202 has spent over 15 years bringing to life and to market compelling experiences through our Experience Strategy & Insight, User Experience, Software Development, Marketing & Analytics, and Program Management practices. Our talented team has delivered emotionally-rich and intuitive solutions for global brands and clients such as 7-Eleven, Capital One, Dell, Mercedes-Benz Financial Services, Samsung Electronics, Neiman Marcus, and The Container Store, among many others.