A software product’s future is dependent on the quality of its backlog; a prioritized list of items you intend to complete in order to improve the product in the future. If you don’t have a list, the product will most likely fail. Even if your list is written on the back of a napkin, it’s a start. 

In other words, a software product that’s not expected to adapt to its market is doomed to die the day it’s released. Software products that are expected to adapt to changing user needs and market conditions are set up for success. There is no such thing as a perfect software product or an all-knowing software product development team. If we want to build a software product with a 100-year future as a critical brand asset that builds relationships with customers, we need to take the backlog seriously.

A healthy backlog is a critical part of a software product’s life and future. We need to spend a significant amount of energy defining what it means and why it is an important ongoing investment for our firms. Thus, the backlog is a measure of critical concerns regarding a software product:

Product vision.

measure of how aligned your team is with the product vision. A lack of new ideas, refinements and innovations would indicate a lack of alignment or a poorly defined vision. A crisp, executable backlog would indicate that the vision is clear and your team is aligned.

Motivation.

The size of your product’s backlog serves as a measure of how motivated your team is regarding the product’s future. A smaller, more fixed set of future deliverables would indicate that your team is not putting much thought into your product’s future. A large, dynamic and vision-aligned backlog would indicate a great degree of motivation.

Organizational Commitment.

The pace at which you invest in your software product is a direct measure of your organization’s belief in the promise of the product and the capabilities of the team. Without the proper investment in skills, tools and the product itself, your teams will be frustrated.

Efficiency of Your Team. 

The size and quality of your executable backlog serves as a measure of how efficiently they operate together. A disjointed backlog that is not clearly set in the short-term may indicate that you have the wrong skills or poor leadership. If your team is consistently struggling to understand, or concerned with what to work on next, it may be an indicator of an unhealthy backlog. A crisp, executable backlog would indicate that the vision is clear and your team is aligned, motivated and well-organized.

So what does a healthy backlog look like? I assume that it is slightly different for every product and product development team, but here is a relatively simple structure for discussion:

Ideas.

These are the features and functions that we may build into a product that is aligned with the long-term vision for the product. These are rough ideas that we capture, but are not defined enough for our teams to associate any relative size to them. Ideas may never come to fruition and that is OK. The business may simply not have the budget to push them to the top of the priority stack. There may always be more innovations that provide more value to the users in front of them that need to be built first.

There is no limit to the number of ideas that can be associated with a software product and we could be measuring the flow of ideas into the system and into backlog items. If either of these flows dry up, we have a problem. The flow (or raw number) of ideas being created and converted into backlog items is an early indicator of product trouble. 

According to Adam Grant, procrastination provides some amazing benefits to creativity. It is in our minds while we are procrastinating. Our minds are working on ideas in the background. Capturing the ideas and opening a dialog around them, however distant they may be, gets our collective minds thinking about the possibilities and working on refining them over time. As we move about our work and lives with these ideas in the background of our consciousness, we will be more likely to observe interactions that spark creative ideas that will improve our products. 

The Backlog. 

This is the list of things we have decided we want to build at some point. These are the features and functions we have all agreed upon, a relative size for the purposes of product road-mapping. When I say sized, I mean we have asserted an educated guess as to the scope, but not hard and fast commitments. We call these “T-shirt sizes”, and they allow us to start to frame a high-level roadmap around them and assign them to epics. Epics are collections of stories we plan to implement at some future time.

Over time, we groom them in an iterative fashion. We improve them with more and more details as we learn what we need to do to accomplish them. Backlog items, however, are not yet fully groomed. It is not possible to assign them a fixed size and the breadth and depth of scope for these items has not yet been fixed. They may be broken into multiple stories or combined into stories when they are made executable. In fact, we are always looking for opportunities to split them into smaller stories that are easier to execute more accurately and efficiently.

There is no limit to the number of items that could be placed in the backlog and the relative T-shirt sizes could be accumulated to provide some relatively predictable long-term measure of the product’s future. The long-term backlog could be regularly assessed by the business to determine and regulate an acceptable pace of feature delivery versus the value of the product to the business. The size and rate of growth of these backlog items are key indicators of product’s long-term success.

Executable Backlog.

These are the items in your backlog that are executable tomorrow. They have been sized and your team has everything required to execute on them. The optimal size of a product’s executable backlog is different for every organization and every team, but at a minimum, the executable backlog should be at least two sprints out.

An agile purist may argue that the further out you go in clearly defining your executable backlog, the more likely you are to create waste because those items will likely change prior to you executing them. However, having a few sprints worth of high priority, well-defined items in advance allows a couple of things to occur for the business that would not be otherwise possible:

• It gives the product teams a little time to think about the upcoming work. Allowing a small amount of creative space between definition and delivery will produce a better product. People with a small amount of creative space who are aligned with the product vision will have a chance to refine and propose new ideas for your product that will be valuable.
• It gives the business a few more choices right up until they lock in the very next sprint. Business people like to have choices and feel in control. If they have several options from a pre-prioritized list they have more ability to adapt to changing market conditions. If they feel in control, they can also be more creative with how they approach their markets.
• It creates a knob, literally. If you have more items that are ready to be executed, it makes it easier for the business to invest more in their software product if the business warrants it. If you are constantly at the edge of creating requirements, just-in-time, there is minimal ability to turn the knob and increase the throughput of your development efforts. 
• It creates a slightly less stressful environment for the business leaders who are responsible for approving and grooming the backlog. My argument here is that this only works if the development team is mature and competent enough to do some of the heavy lifting on product grooming for the business, to relieve some of the pressure on the business team in the process. Some may argue that some stress is good, and I would agree. But, like anything else in software development, it’s about finding the balance.

Going back to the distinction above of a minimum executable backlog, you should never be defining items or revising items during a sprint. You need to always be at least one full sprint ahead of your team. For the reasons above, the minimum executable backlog should be at least two sprints ahead of your team’s current pace. Anything less results in an unhealthy amount of stress and puts a strain on the business. 

The optimal executable backlog should be at least two times that amount. Your business should have the ability to double its pace when it’s ready to, without having to scramble to ramp up an executable backlog to execute upon. There will be a little bit of waste in defining items more than a couple of weeks in advance, but the value it brings to the business and team outweighs this minimal amount of waste. You will end up with a more robust product, a more motivated and fulfilled team and a knob that you can easily turn up (or down) for your business if additional resources become available (or become constrained.)

Developing a robust backlog represents a significant investment of time and energy from both your product development team(s) and the business, but it will pay off in spades with the increased flexibility and dynamic choices that the business will have involving their software development investments. A software product’s future can be predicted by the quality of its backlog and the alignment of that backlog to the mission. If you believe it has a future, invest in the backlog.