Product Backlog: Avoiding the Dreaded Backlog Rot
We oftentimes have requests that are submitted through well-meaning stakeholders that fill up our backlog. When those requests come in, we try our best to honor the mantra of anyone can add items to the Product Backlog. However, what do we do to ensure that the Product Backlog doesn't become unmanageable. There are 3 keys things to remember... First, The Product Owner is the person to prioritize the requests. Second, No should be a readily available and used word. And Third, there is a healthy balance of how deep your Product Backlog should really be at any given point in time.
The Product Owner Prioritizes
Many people will give input and insist that their items must be done first. Many years ago when working with a Product Owner, I recognized that he had the title in name only. He was a bright, well-meaning person but he never truly had the authority to prioritize the requests that came from various external customers and internal stakeholders. It was readily apparent partway through a given sprint that this Product Owner approached the team in a frenzy to give some bad news... everything being worked on needed to be stopped because all funding had been pulled from that initiative. It was met with much grumbling, complaining and the team asked how this could possibly happen since the Sprint Planning session had just happened a mere couple days previous. As the sprint was terminated that day, many discussions ensued in the Retrospective and very rough Sprint Planning session. How could this possibly happen that quickly into a sprint? The short answer I discovered as a ScrumMaster was that our "Product Owner" was not really empowered to make decisions for the products and initiatives he was "in charge" of for the company.
It is imperative that the Product Owner be the decision maker. It is for their good and for their ill. They are the ones that chart the course based on input they receive from stakeholders and various analysts around them so success is maximized and failure becomes a learning mechanism to enable success. How are we making sure that the Product Owner(s) in our company are not just there in title only, but they are truly helping chart the path of our products and initiatives? This becomes not just a topic of trust by executives but also an exercise in patience and support from everyone that works with them. The Product Owner is not successful without everyone around them providing feedback to help enable good decisions and then letting that Product Owner make the decision.
The Magic Word is "No"
I will never forget how passionate someone gets when they approach me with what they believe is the best idea that has ever existed in the world. Sometimes, they really are good ideas. Consider this one for instance when I was a teenager. I remember hearing a radical idea about not using a typewriter to complete a report to be submitted for school. The requirement of the assignment mentioned that it should be submitted typed and double spaced. Someone mentioned I could use a word processor where I could read through, spell check and check my grammar before ever printing the paper. It sounded like a great idea to me so I tried convincing my parents to buy a word processor for our home so I didn't have to spend time in the school library after school hours to get my paper typed up and then saved onto a floppy disk for future use. I was met with a resounding "No". I was shocked at how my parents could be so short-sighted and how wonderful that word processor would've been not just for me but all my siblings. Dejected in my request, I dutifully completed all the work at school and got it printed there to be submitted for my assignment.
Several years later while I was in college, I was living at home and my father came to me and asked why I thought it was so important to have a computer in our house that I had just purchased and set up. I proceeded to show him all the various things that could be sped up with the use of applications on the computer. He was drawn to the word processing capabilities of the computer and several other things where he could communicate through e-mail with some of his clients and family members. It was revolutionary. But I wondered why did it take so many years to recognize that value to have such a value tool in our home. Sometimes the value of "No" is misunderstood. The original decline I received in my request had more to do with the large investment that word processor was going to be and there's no way it could fit into the family budget. Time can change the value and effectiveness of ideas where "No" was originally conveyed.
If we are presenting the idea and hear that magic word, how do we respond to the Product Owner? Do we respond as the 3 year old who has been refused a piece of candy 10 minutes before dinner? Do we try to understand more of what is currently being done and the value of the current items that are of higher priority? We need to allow the Product Owner to make that decision of when they say "Yes" and even more importantly... when they say "No". If we think they are just an order taker, we are undervaluing the vision and strategy that the Product Owner has in mind for the success of our products and initiatives.
In the past year I have seen Product Owners act frantically as if they need to say "Yes" to every request that crosses their desk. They feel obligated to help everyone with everything. More frequently though, I am seeing Product Owners make the decision that they want to have an earlier release of the product being worked on. In some cases, they have reshuffled the Product Backlog to have an earlier release possible. In one case, I remember hearing a Product Owner explain to a development team member that they no longer wanted the feature that they were about to start on in the next sprint. The team member was upset and concerned that it wouldn't allow them to finish what had been envisioned or "started". As the Product Owner listened, he responded after the retort finished with something such as this...
"It is more important to me that we find out whether we are really on the right path with the current build of our product before we add more features. Our product needs to be stable and valuable. When it is stable, we can look at other features to be added to see whether there is more value that can be added but we need to get it released to see what value we really have created."
Healthy Depth of the Product Backlog
Many people have worked with lists of features over the years that seem to be never-ending. Oftentimes we see the Product Backlog appears to have 1 year, 2 years of even more work that is queued up to be worked on. In such a rapidly changing world, is that level of depth really necessary? Will those items still even be relevant as you get 2 years into your effort? I believe we all recognize that paths change, priorities change and desires of customers definitely change over the course of time. This brings to light the need to have a pulse on the need to change, reprioritize and get the right things completed. When the list of defects, requests and features has been sitting in your Product Backlog for 2 years, 3 years or 7 years, what do you need to do in order to make a decision on what is in and what is out of that Product Backlog?
I have seen many strategies employed that are successful here. All of them have the same core principle behind it... a decision needs to be made for what we are focusing on now, what is being done next and what will be coming up in the near future. I have seen this take a list of product defects that tracked back over 5 years with several hundred items get trimmed to a little bit less than 100 items. It required a highly engaged and passionate Functional Analyst who also served as the Quality Assurance Analyst in that particular organization to give feedback to the Product Owner to help them with their decisions. The teams that worked on that product suite wanted to have a stable product, but where did they even start? After laying out the items in a very simple fashion of what still existed in the system, the Product Ownership Team was able to determine whether something be Fixed Now, Fixed Later or Do Not Fix It.
So, you now ask, what is the right depth to our Product Backlog? A wise Product Owner, Peter, expressed some sentiment about feeling bad that "we never get to those things further down on the list". He shared how when other items become higher priority those great ideas that were just beyond the near term just didn't seem to bubble up to be worked on. The concept of refining or grooming that Product Backlog becomes important to avoid what Peter called "Backlog Rot". If it has been sitting on the list for a while, will we ever be working on it? Does it need to be moved off the list for a while until there is something that makes it more important? Should it ever be focused on? This again is where we circle back around the the decision maker we call the Product Owner.
For some products or initiatives the depth of the Product Backlog is enough when it is 1 to 3 months deep. The rapidly changing nature of those products readily needs to capitalize on market opportunities now instead of a few months or years from now. Other Product Backlogs are healthy at 6 months to 12 months deep. When the list gets beyond a year, much will change before it gets to that point which suggest that it doesn't require a significant amount of focus on requirements gathering, estimation or other activities to be conducted before the timeframe becomes closer. I have heard many executives and Product Owners echo the following sentiment..
"I need to make sure we are going to market sooner than later. We need to be within the first couple to market with this solution. We can't be 3rd or 4th to market because we will just become an also-ran. That is not a profitable position for us. We need to be setting the trend on what to do by our early go to market strategy."
Make sure the Product Owner is truly empowered and supported as the decision maker. Remember that the answer "No" is just as valuable if not more so than the answer of "Yes" when considering whether something should move up in priority on the Product Backlog. And finally, keep your Product Backlog fresh to truly roll to market early and valuable solutions and products. I welcome all of your thoughts and ideas on what you continue to see in the marketplace as valuable approaches to Product Backlog management.