Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
A large backlog is a problem. A fat backlog will impede innovation and cause a frustration. Is our ability to generate ideas paradoxically one of the biggest impediments for new ideas?
A large backlog is a problem.
A fat backlog will impede innovation and cause a frustration.
Is our ability to generate ideas paradoxically one of the biggest impediments for new ideas?
Once upon a time I was working in a lab team with the goal to come up with new ideas/products to enhance the company’s offering. My personal goal was to come up with one idea per week, some good and some less so. After months and months of creating prototypes and seeing them all burn in the trash bin my first thought was that I only had crap ideas. But some of my game ideas were played internally to such extent that they had started to invade work time, so I started looking for other reasons. I came to the realization that the product owner function in the organization had such a large backlog with future work that it was impossible to maintain. Any new idea will end up at the end of a never ending queue and when, if ever, it is time to be realized it would have rotted. Needless to say I moved on shortly thereafter.
In an agile development organization the main tool to manage the roadmap and gain predictability is the backlog, but if it grows uncontrollably the value it provides is diminished. An unreasonably long backlog is a major pain point for many agile teams.
A fat backlog will eventually lead to the team abandons it and resorts to reactive sprint planning, the shear amount of information becomes unmanageable and often irrelevant. In turn it means that the teams will lose sight of the long term goals and end up in a very task focused environment; it’s just so much easier to think about what you need to do than what to achieve.
A fat backlog causes a lot of problems, but to name three:
Queues cost maintenance
We suffer from a blindness to queues (Reinertsen, The Principles of Product Development Flow, 2009, ss. 5-6). Queues incur cost; each item will continuously require a little attention to remain valid. Grooming a fat backlog can seem like an insurmountable task, which means that it is omitted. Eventually this leads to the entire backlog becoming obsolete.
Information value reduction
Each item in a backlog of tens of thousands of items will seem insignificant and adding a new item to it will feel pointless. A fat backlog is essentially a trash bin where all work you want to do, but never will ends up.
Inhibited innovation
The first two points only talks about number of items in the backlog, but if you also consider the amount of work required to complete a fat backlog it will inhibit innovation. Since reorganizing a fat backlog is such a tough chore, new ideas are either added at the front or the end of the backlog. Adding items to the front means that you are invalidating the rest of the backlog, adding them at the end means that they never will be done.
With these problems in mind we need to look at how backlogs become fat. There is not a single cause, but some of the following behaviors can most likely be held accountable for fattening the backlog.
Hoarding
Humans are by nature hoarders, we have a hard time throwing away anything, especially good ideas. The key to successful backlog management is not to know what should go in; it is deciding what should go out.
Information need
There is a lingering belief that keeping track of everything at a granular level gives us a good idea of the scope. However, as responding to change is an important part of agile development the further in the future we have plans the less certain they are. Thus the granularity needs to reflect that. In the term DEEP, which is often used to describe a good backlog, the D stands for Detailed appropriately which describes the solution to this problem.
Dependency resolution
We are not truly agile and strive towards resolving dependency chains in the backlog into the far future. In order to identify dependency chains we break down larger items into their components, we reduce the goals into tasks. This has a double negative effect on the quality of the backlog, firstly it makes the backlog balloon, secondly it means that our backlog isn’t value driven anymore it is heavily focused on what work we need to do.
Lack of commitment to the product owner role
Most products organizations have way too few product owners in comparison to the team size, and they have limited time to manage the backlog. The product owner responsibility is something that shouldn’t be taken lightly.
To test where you are right now, do the following:
Write down the number of product owners there are in the whole game team. If you don't know, that's the first thing that should be fixed.
Write down the size of your backlog.
Divide the number of items in the backlog by the number of product owners.
In our experience each item in the backlog will need about 5 minutes discussion for everyone to get a rough understanding of it, so multiply the number of coming out from the step above by 5.
The resulting figure is the approximate average amount of time it will take for the teams to go through their backlogs. Is it even remotely feasible?
If the answer to the above question is no you might want to consider trimming the backlog. Here are a few advices that you can use in such an effort.
1. Take the Product Owner role seriously
There should be one person, no more, no less, responsible for the backlog of each team. Ideally, that person is only responsible for one team backlog as well. That person needs to have plenty of time available for maintaining the backlog in collaboration with the team and the game direction. She needs to be knowledgeable about the product and have the authority to make decisions within the backlog without involvement of other parties.
2. Decide on a DIP-limit on number of items and amount of work
A good starting point would be to start looking at your Design in Process (DIP) inventory, coined by Donald Reinertsen. What you want to do is set a limit for how many items you can have in the backlog. There is not a size that fits all, but a starting point would be to look at it as a size per product owner (PO). Since a PO is mainly responsible for a backlog, her capacity to administer the information is the limitation. Thus, a large product with ten PO’s, responsible for different areas, could have a backlog that is double the size the backlog of a product with five PO’s. A generic advice we have heard is that Dunbar’s number is a good guidance in this situation as well, which means that one PO could handle around 150 items at any given time.
We should also consider DIP for amount of work to ensure that our pipeline isn’t planned for years and years as this could seriously inhibit innovation. However, it’s hard to give a generic advice on how long a roadmap should be as it depends on a lot factors, such as game type and market maturity.
3. Decide how to manage the backlog
Create a simple and clear strategy of how you will manage your backlog and involve the team in that process. The product owner holds the responsibility to maintain the backlog, but she is not the only one that contributes to the vision. Everyone on the team can and should contribute and continuously participate in the process of keeping the backlog fresh. For this to work, everyone needs to have a rough understanding for backlog as this is the product’s vision and roadmap.
As a starting point, this article; How to Hold an Effective Backlog Grooming Session hands out some useful advice.
4. Make decisions
Restrain yourself from entering every idea that comes up, keep it in your head and if it still is in there after a week it might be worth adding to backlog. In association to that you should have a soft “one in, one out” policy as you are hitting the DIP limit you have set for yourself. And yes, it is hard to discard things but having that ability is an important trait of a product owner.
5. Work with an aging idea funnel
A product backlog, and a team backlog, can be divided into several stages where the DIP limit could be tougher and tougher the closer they are to implementation. The simplest approach would be to have one portion of the backlog to store new ideas, and one portion which is more thoroughly groomed and restricted in size. Give the ideas an age limit so that the ones that are not being prioritized are disappearing over time to avoid flooding this part. When the idea is moved to the next part, it indicates a commitment from the PO that this idea will actually be implemented eventually.
6. Do not game your own rules
If you apply strict DIP limits you might be tempted to bypass your own rules and instead pack an abundance of information into each item. Don’t do that.
Hopefully this will take your backlog from being an overweight colossus to lean manageable roadmap that will help you get innovative ideas into games.
Co-author: Johan Karlsson
Read more about:
Featured BlogsYou May Also Like
