Overcoming the Roadblocks in Agile Backlogs
Many teams that operate within Agile are struggling. The story is the same for an abundance of them—the Backlogs from which they operate fail to provide clarity on priority, definition, and scope. The teams are left with more questions than answers and have no clear path to creating value for the organization and customer.
We find that the backlogs that Agile teams frequently operate from appear as a thematic list of items that the product owner wants built. These macro-projects may span multiple sprints and prevent the teams from producing increments of working, tested product each sprint. Without achievable incremental progress, the teams’ velocity of output becomes unknowable. Without a stable team velocity, we become unable to make and meet commitments, causing future planning to be unreliable at best and impossible at worst.
Alternatively, backlogs may appear as a ream of minor engineering activities that are too small in scope to convey tangible value.
Neither of these methods of Building Backlogs provide clarity to the teams on the What, When, and Why of the project. The teams are left scrambling, unsure of what to prioritize with no clue how much of it can be completed in a sprint. Time becomes wasted searching for answers to these questions and can cause unwanted outcomes for the teams, the product owner, and the customer.
It doesn’t have to be this way.
Backlogs can and must be built in a way that provides clarity to the teams and allows for measurable, iterative progress to be made.
Rethinking Backlogs
Backlogs should consist of stories that allow for measurable progress. These stories must be small enough in scope that more than one can be completed in a sprint. They also must be large enough to provide tangible value to the product or feature and have meaning to the customer. The stories should not be prescriptive and must be open to negotiation for priority.
The scope of each story needs to be clear enough that the teams can estimate the time required for each and complete them within the predetermined time box. Each story needs a clearly defined state of “done” to allow for progress and prevent technical debt. The stories must be able to be exchanged for new directives if (and when) we learn new things. When we build backlogs in this way, we give the teams clarity around what they are building and how what they are building fits into the bigger picture.
Why is It Difficult to Build Backlogs This Way?
In many organizations, the individuals who decide what goes in the backlog aren’t available to provide clarity to the teams. Additionally, the stories are poorly defined and give insufficient directive. As previously discussed, the stories may be too big and span multiple sprints, thus preventing incremental progress to be made.
Team members may not have the authority to decide how to prioritize their work, and competing demands or too much WIP further prevents clarity on what to prioritize. Product owners that continue to build backlogs in this way prevent teams from stabilizing their output and optimizing their productivity.
How to Overcome the Difficulties of Building Backlogs in This Way
We must have open communication between the product owner and the teams completing the Backlog stories so that the teams produce increments of product that are most valuable to the customer and the organization.
User stories should be defined with enough detail that the team can execute on the delivery without having to ask excessive clarifying questions. This allows teams to produce working increments of product during each defined time period with confidence that everyone is on the same page.
We must lead our Backlog Building with a Systems-First approach—this entails prioritizing the creation of value over accomplishing tasks and projects. We must align our organizational structure and the way work flows through the system around a value-oriented approach. Building Backlogs in this way creates a team environment where we learn and adapt and expand our capability while ensuring the incremental work that we produce is valuable to the customer.
The Value of Building Better Backlogs
When we build better backlogs that support the teams, we become able to produce working, tested increments of product at a stable velocity. When we know the velocity of our output, we increase predictability and can reliably make and meet commitments.
Incremental and iterative delivery allows teams to track their progress, ensuring that they deliver and demonstrate value to the customer every sprint. Additionally, they become able to make tradeoffs based on scope and prioritization and adapt to changing customer demands and markets.
Providing teams with clear and actionable Backlogs empowers them to create value at a stable cadence with clarity around why and how their work is important to the organization.