Intro to Part II
For those of you just joining us, my name is Joey Gibbs and I work as a Development Manager on the game Research & Development team at Riot Games. In this second article of a two-part series, you’ll learn six heuristics that can help your product teams make the most of their time just by changing how they prioritize their work. While my focus will be on game development teams, the project management strategies discussed today are broadly applicable across many different software development contexts.
Recap: Vision, Mission, & Product Backlog
In my previous article, I talked about establishing a project vision and mission to help align your team around major objectives. A vision statement depicts a future state of the world in which the team has achieved their goals. The mission describes how the team plans to achieve that future state. Your product backlog, then, is a checklist of all the work the team will have to accomplish in order to complete the mission and realize the vision. When breaking down the mission and building out your backlog, I suggest defining your product backlog items (or PBIs) first in terms of the outcome they create (that is, the experience they create or the behavioral change they drive in players) as opposed to the output the team generates (a particular feature that’s intended to create the outcome). While it’s the team’s collective responsibility to make sure that they’re chasing the right goals in the most effective way possible, teams at Riot rely on a team member designated as the “Product Lead” to make sure those conversations are happening.
With the team properly aligned and the PBIs prepped and ready, there’s just one question remaining: What should the team work on first?
Development Strategy
I use the term development strategy to describe how teams choose to tackle their backlogs: what they decide to do, when, and for how long. As a product lead, you can help your team thoughtfully order their backlog to optimize value delivered to players while minimizing resources used and time spent. While creating an effective development strategy is by no means an exact science, here are 6 heuristics that can help your team get the most out of their time:
Heuristic #1. Stack rank. Strictly.
Let’s start with a simple, high-level backlog for a hypothetical action game in which players work together to fight against enemies controlled by AI bots. First, let’s generate a list of outcomes that we want to drive for our players:
Next, let’s flesh out our backlog by creating a few outputs that we think will generate those outcomes. This list of outcome-to-output PBIs might come out of a very early planning session in which the team is brainstorming features for the game. And as you can see, each outcome can have multiple outputs supporting it:
For the sake of brevity, I’m going to tl;dr (too long, didn’t read) the outputs for each of these PBIs into more manageable shorthand. As a product lead, I’ll still take the time to define the outputs with the team in detail, but when it comes to the day-to-day I’ve found that developers generally don’t refer to work in the “As a player, I want to _____.” user story format.
Once the list of PBIs is defined, work with your team to sort that list top-to-bottom in the order in which you plan to do them. Boom. Stack rank. I say “stack rank” instead of “priority” because priority can mean different things depending on the context (don’t worry, we’ll hit PBI stack rank modifiers like player value-add, priority, and urgency a little later on). For now, just remember that stack rank means order of execution. Remember to stack rank strictly (1,2,3,4,5,6,7,8,9,10 instead of 1,1,1,2,2,3,3,4,4,4) because you’ll want your team to get into the habit of pulling from the top of the stack when they’re looking for things to do. If there are three #1 issues to work on that decision gets complicated, and it doesn’t need to be. The end result might look something like this:
Now, some of you might be thinking “That’s a nice list and all, but there’s no way we’d those work items in that order.” Totally valid. But bear with me: With your list of PBIs defined and stack ranked, it’s time to modify that stack rank based on a few common project parameters like player value, urgency, and risk.
Heuristic #2. Maximize marginal returns to player value.
Holding other variables like urgency and dependencies constant for now, make sure that the most valuable features are always higher up in the stack rank. Each feature completed should add value for players, but not all features are created equal: Work with your teams and stakeholders to determine which features are considered to be the most valuable and do those first. Why? Because odds are you’ll run into design changes, refactors, and other necessary found work that will cause your estimates to grow and your feature backlog to swell. If you’re strict about stack ranking and always working on the highest value-add features, even if you run out of time or resources you’ll have done the best you could with the time you had. After a conversation with your subject matter experts or SMEs (typically leads from disciplines like game design, art, engineering, etc.) you come away with a better understanding of the content and features your players will get the most enjoyment out of. To keep things simple, I’m using a 5-point scale to indicate player value, in which 5 is high and 1 is low:
Now just change your stack rank to optimize for incremental value-add to players:
Alright! That looks a little bit more sane. Now that you have a strictly stack-ranked list of things to do modified by player value-add, let’s talk about urgency. Because after all: Why do today what you can (responsibly) put off until tomorrow?
Heuristic #3. Important != Urgent
Just because a feature is valuable doesn’t mean you have to do it today. Your individual project context will determine which problems to solve now versus which ones to put off until later. Remember that load test harness for the game server from the first article? Important, but not necessarily urgent unless a lot of players are about to hit the server at the same time. Early in development, the load test harness is probably a lot of work for not a lot of immediate value. Further, the opportunity cost of working on it early on is high: The engineers working on the load test harness could focus on something more immediately valuable, like tightening up the ideate/build/test/repeat feedback loop by speeding up the build pipeline. Because of those considerations, in this example you should drop the load test harness lower in the stack rank.
Now let’s get back to our example backlog. What other PBIs are important, but less urgent? To focus the exercise, let’s assume for now that this project is still early in development and load testing isn’t particularly urgent. An urgency-adjusted backlog might look like this:
Do you see any trends? Because our example project is still early in development, I’m helping the team prioritize development on core gameplay interactions (basic pve combat, in this case) and build/tooling improvements to help speed up iteration times. The load test harness has made its way to the bottom of the stack rank because, again, it’s important but not urgent.
Heuristic #4. Solve the scariest problems first.
It doesn’t matter how much value your team has created already if something happens that could cause the project to get cancelled outright. To help prevent this and other common game dev catastrophes, have a conversation with your team early on about what scares them (and I don’t just mean the crushingly oppressive weight of existence). What kinds of delays could happen, putting your ship date at risk? What could make your publisher pull funding? Can the team really pull off that risky technical feature? Identify the big scary things, develop risk strategies to prevent them, and add them to the list alongside the rest of your features. Put the worst ones as close to the top of the stack rank as possible. If you’re screwed, you’re going to want to know sooner rather than later so that you at least have an opportunity to respond.
Let’s say that our example project is planning on beating its competitors by having world-class AI-controlled opponents. As the team’s product lead, you know that your tech lead is sitting on some hot new machine learning tools that she wants to incorporate into the advanced AI characters. The only problem is that she hasn’t had time to test it yet. Your team reasons that without cutting-edge AI, it’s unlikely that the game will stand out from the crowded co-op action game market and therefore is less likely to be successful. In this situation, what should happen to our backlog? Let’s make managing these PBIs even easier by simplifying per-item risk levels down to low, medium, and high:
If the process were as simple as mitigating risk, we’d start on Advanced PvE AI right away. As it stands though, there are a few things blocking Advanced PvE AI development. Now’s a good time to talk about managing dependencies via stack ranking.
Heuristic #5. Manage dependencies.
Have a PBI on your backlog that can’t be started until another PBI is complete? Unless you have a massive organization you don’t need a complex gantt to keep track of dependencies. For this heuristic, work with your team to identify any finish-to-start relationships that might exist between work items. Here’s an example output of that conversation from our action game project:
With dependencies defined, let’s take one more pass at stack ranking our backlog:
Alright! We’re looking a little bit more sane. To recap: Our development strategy is to de-risk the project by focusing on proving out core gameplay interactions (basic combat) and tech that we think will make our game stand out from other similar products on the market (adv pve AI).
While we could stop there, as an experienced product lead I personally have some concerns that we’re not investing in tooling soon enough. Let’s use one more section to make some final changes to our stack rank based on game developer intuition.
Heuristic #6. Trust your team, trust yourself.
At the end of the day, be sure to make adjustments to your development strategy based on input from the team and from your own prior experience. You can take the time to apply more rigorous effort to evaluating the player value add of feature A vs. feature B (maybe the subject of another article?) but at some point you have to accept that you’ll never be able to predict the future - you’re going to have to act on imperfect information.
Looking at our dependency-adjusted backlog, I have a bad feeling that the team is putting off important development tools for too long. Faster build times and smoother 3D asset imports mean faster iterations, and I know from experience that more iterations lead to a better product. Now, I wouldn’t make any changes to the plan without consulting with my SMEs first, but based on all of those considerations I’d go into that meeting with a straw-man “final” backlog that looked like this:
I’m sure you have your own opinions about what’s valuable to players, what’s risky, and ultimately which order to attack the work in. And that’s okay! Everyone will have a different perspective, and it’s not always clear which approaches will yield the best outcomes. At the end of the day, it’s the product lead’s responsibility to make the final call. But by including your team in the planning process and taking a structured approach to driving these conversations, you’ll increase your chances of doing the right work at the right time, ultimately generating the right outcomes for your players.
Conclusion to Part 2
Alright product leads, let’s recap the full two-part article series:
First, we started at the 10,000 ft. view by defining the vision and mission for the project. Then we broke the work down into more manageable chunks, defining our product backlog items in terms of the outcomes we wanted to drive with our players. From there, we worked with the team to ideate outputs - things we wanted to build that we felt had a good shot of realizing those outcomes. With the backlog in place, we came up with a plan for tackling the work in a deliberate order according to the following heuristics:
Leverage strict stack ranks so that the team always knows what to work on next.
Always try to make the most player value with your time.
Sometimes things that are important aren’t important today. Do them later.
Go after the big risks first - if you’re gonna fail, fail fast.
Adjust for dependencies.
Modify your plans appropriately based on experience.
The output of this stack-ranking exercise is our development strategy: the path through the work that represents the shortest distance between the world of today and the world in which the team’s goals are realized.
As the team chews through the work, it’s your job as the product lead to drive user research and testing, evaluating whether or not the freshly minted outputs are creating the desired changes in player behavior. If the outputs aren’t effective, no problem: it’s all part of the learning process. Work with the team to plan new outputs that better match your desired outcomes and give it another shot. But let’s say instead you release an output and players respond the way you hoped they would. If you’re doing your high-level alignment correctly, you should be one step closer to executing your mission and realizing your vision.
That’s all for now on development strategy. Please be sure to check back with us later for fresh articles, including deeper dives into some of the topics I’ve touched on here today!