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:
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.
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.
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:
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.
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.
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:
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.
We are interested in learning more about your company and its technology pain points. ITX takes a no strings attached, consultative approach in order to get a better understanding on how we can help align your technology to better serve your target market. Our Technology Consultants are excited to sit down and help roadmap a solution to your technology needs.
Inquire today. Let's get started on creating a technology solution that is worthy of your brand.
1169 Pittsford-Victor Rd. Suite 100
Pittsford, NY 14534
Toll Free: 1.800.600.7785
Toll Free: 1.800.600.7785
Let the news come to you. Get our latest articles in your inbox.
Sign up for email alerts to:
Don't worry. We hate spam just as much as you do.
Oops! It looks like your browser is not completely compatible with our website. We recommend updating to the latest version of your browser in order to optimize your user experience. Below is a list of tested and supported browsers that we know will be up to par.