Visualizing the development flow
The quality of a Product Backlog is crucial for organizations that want to accelerate teamwork.
The video shows alternatives for multiple Agile teams working on the same Backlog. The recommendation is to abandon activity-based planning to give Teams the right prerequisites to accelerate their creative journey to accelerate the flow.
The video also covers some basics about the content of a Product backlog.
Product Backlog Content
Two types may distinguish the content of a Product Backlog; user-facing Features and Enablers supporting the delivery of Features.
A Feature is a common term for something beneficial for the end user! These are the items that the customers want to pull. All other items are needed internally in development.
Most of us own a watch that we can use in different ways:
- A primary feature is to see what time it is.
- To get up in the morning, setting the alarm is a valuable Feature
- And some people like to improve their running by reading split times
When an Enabler is done, it should help deliver Features. Enablers are an investment in tools and other prerequisites to advance productive work.
Typical Enablers can be:
- Architectural, as a communication interface
- Or infrastructure, like a Test rig
- Or, to support exploration, a Design System may be helpful
Work Items are all the activities or tasks needed to complete the Backlog content. These items are often part of the plan and may be finalized in one day or less. Look at a development team for a product. There are plenty of things they need to do. They typically:
- Analyze customer needs
- Invent a new design or
- Validate assumptions
In short:
- Features are what we want
- Enablers may help deliver Features
- and Work Items are what we need to do
Agile by the book
By the book, Agile frameworks apply short delivery periods called iterations or Sprints. In the target state, Product Backlog Items, also called Stories, should be done by one Team within one Sprint. Done means everything is ready, so releasing an item to the end user is possible.
When scaling Agile, there may be longer delivery periods, mostly called Planning Intervals or PIs. Each PI consists of several Sprints and is connected to backlog items shared by multiple teams. On this shared level, the Backlog items are mostly called Features and should be business-focused.
When sufficient Stories have been done, the Feature is done. But what about the reality? Especially when a traditional project culture is deeply rooted in an organization.
Activity-based planning
In activity-based planning, few organizations can get backlog items done within Sprints and PIs. A Feature could take three PIs to finalize, especially when multiple teams are involved.
In the pursuit of having backlog items contained within PIs, breaking down Features into activities that match the delivery period is common. These are obviously not the preferred backlog content, and Product Management gets trapped in procedures for development work.
If the goal of one PI is to do traditional project activities, also the Teams get trapped in preparatory work instead of creative value delivery with real user feedback. Enablers may be done and are beneficial, but it is still not the short learning cycles needed to get rid of all uncertainties in Feature development.
Then, what is the best way to move toward early and frequent value deliveries on all levels? Can something be done about the restraining activities defined for each PI? Since the activities exist because of working procedures, removing them will not interfere with end-user needs.
Business-focused Features
Let’s put Business features in focus!
If Features are brought to the teams as is, there is a better chance to understand business benefits and start learning to create smaller deliverables. Maybe the first Sprints are dominated by activities. But further on, more Stories may emerge in each team. In the second PI, an Enabler is defined by several Teams, and after three PIs, they agree on a new Feature based on learnings from practical collaboration.
Exploration and courage can transform a mindset of preparatory activities into a mindset of trust in finding solutions and getting stories done in each Sprint. Avoiding activity-based planning is crucial, which gives teams the wrong prerequisites. With business focus and trust, Teams take responsibility and deliver in their best capacity. In the long run, there will be prioritized backlog content, making it possible for multiple teams to deliver what we want in every Sprint and in every PI.
About the content
The intention of the Articles published on this website is to provide exciting knowledge about organizational development in any business. BDD hopes this knowledge will help take your organization to the next level. The information is based on our experience supporting many transformations and cutting-edge sources published in books, articles, and frameworks.
