GIST for Games (Development): Is GIST the Right Tool for Your Project Planning?

One of the weaknesses of the game industry is that we are fairly slow to adopt new processes. A great framework that has come out in the last few years is GIST. It allows teams to eliminate the use of road-maps and stay Agile in their planning as well as their implementation. This article will give you an overview of the GIST framework, and drill down into how it can help solve common issues encountered while making games. It will also address some of GIST’s limitations and try to give you an idea of whether it might be right for your team.

What is GIST

GIST is a lightweight planning system designed with Lean and Agile goals in mind. It is built to be change-friendly, have lower management overhead, improve team velocity, help foster autonomy, and facilitate better cross-disciplinary alignment. The focus is on building things the customer wants with decision making driven by evidence over feelings and gut reactions.

The framework is named after its main building blocks: Goals, Ideas, Step-projects, and Tasks. There is a fun little coincidence of naming here. In Dutch, “gist” means yeast, the driving force behind beer fermentation, bread making, and other fun stuff. Since I’m an avid beer brewer and the co-founder of a Dutch-based organization, I liked this little correlation.

Going back to the GIST system, here is a breakdown of the building blocks.

Goals describe the company strategy in terms of desired outcomes without specifying solutions. Goals have a planning horizon of one or more years, encouraging your team to think long term.

Ideas describe possible ways to achieve specific goals. Ideas are constantly collected and prioritized (more on this later).

Step-projects are small objectives that can be achieved in 10 weeks or less and are additive to achieving an overall goal. Step projects are defined on a quarterly basis, the team selects goals they want to focus on and ideas they want to pursue that quarter and then defines step-projects accordingly.

Tasks are the smallest part of the system and well understood by agile planning, they are bite-size activities that break down the step project. If you are using scrum you could think of these as traditional “back-log” items. Tasks have a typical planning horizon of one to two weeks and fit in nicely with existing Scrum and Kanban approaches to development.

Idea Prioritization with GIST

One of the key components behind GIST is how ideas are prioritized. The process uses a scoring method that takes into account three main attributes: Impact, Confidence, and Ease (of implementation). Because we all love acronyms this type of scoring is referred to as ICE.

Impact is an estimate of how much the idea will positively affect the key metric/s you are trying to improve. Examples might be: Daily Active Users, Conversion Rates, Lifetime Value, Perceived Usability, and Session Times. Whatever is meaningful for your team to measure based on the type of game and play experience you are looking for.

Confidence is an estimate of how sure we are about the impact the idea will have. This measure helps us stay honest about our impact and ease estimates (things we are bad at estimating by themselves), and it gives us a way to quantify sources of data that inform our confidence level. Lowest confidence is given to things like self-conviction and planning, while highest confidence is given to live ops data and the results of targeted testing.

Ease (of implementation) is an estimate of how much effort will be required to realize the idea. It is estimated on the basis of weeks with less than one week providing the highest Ease score, and 26+ weeks providing the lowest.

An ICE score is found by doing a simple multiplication of these three variables. Here is an example table of ICE scoring for a number of features for a AAA PC 4x game:

Idea	Impact	Confidence	Ease	ICE Score
Twitch integration	8	0.5	8	32
Quick add Discord invites	8	2	8	128
Custom unit builder	6	7	4	168
Crossplay with new Online Subsystems	9	9	2	162
New scenarios	7	0.2	7	9.8

In the above scenario, the team should focus their efforts on a custom unit building feature, and crossplay (maybe a Discord integration). The other ideas can be revisited when they have higher confidence or if it becomes easier to execute on them. The idea bank should be constantly updated and if you conduct a study that indicates strongly that your players would really like a Twitch integration then you can upgrade that confidence to 3 and maybe work on that in the next quarter. 

This has just been a quick look at GIST. For a deeper dive, I suggest checking out the website of Itamar Gilad, the creator of the GIST framework. He has a number of articles on GIST there and gives workshops on how to use this system effectively. For now, I’d like to move on to a discussion of how GIST can be useful for games.

Applying GIST To Games

Problems In Game Development That GIST Can Help Address

You have disagreements about what the player wants

Have you ever had an argument about what “the player” wants? Even if you are working from personas and gathering tons of data it can be hard to agree about this. Things get even worse when you consider early phases of development like pre-production when you don’t have data from your own game at all. Beyond that people just get really attached to their ideas, and tend to defend them as if they couldn’t just conjure up more if they put their mind to it. GIST can be a really effective tool at helping mitigate some of these issues. By requiring evidence based justifications for decision making you can create a more open exchange where there are rules of engagement for idea advocacy. 

There is a danger here. Some people might try to use GIST situationally while subverting it in other contexts. The framework as laid out by the original author doesn’t get super specific. You have to spend some time defining for your team how to measure confidence and what score to give a playtest involving twenty-five participants versus a structured survey with a few hundred respondents. You need buy-in from everyone on the team to get consistent scoring with informed estimates of ease, a structured approach to impact, and reliable confidence measures.

The most outspoken team members get their way all the time

I know as a designer that it is often the loudest person in the room that gets their way. Ambition tends to be one of the unifying attributes of game designers. We want to see our ideas accepted and implemented. We game designers are house Slytherin, not Gryffindor. GIST helps mitigate the effect of all those designers weighing in. It helps give room to evidence-based decision making so that Ravenclaws and even Hufflepuffs can find their voice at the table. 

You have ever-shifting requirements

GIST is built for the ever-evolving landscape of the lean startup with a focus on tech. As such it is highly adaptable to changing requirements. The hardest part is to still maintain the traditional sprint structure where you see through your tasks set for a specific time period. GIST is a process of constant reevaluation that helps surface the most promising ideas and has multiple planning horizons. It’s like it was tailor-made for a highly fluid and cross-functional endeavor like making a game.

The current process involves too many meetings and a lot of overhead

Making games often involves a lot of meetings which seem to get in the way of “real work” but don’t seem like something you can scale back. Part of the problem is that we often have warring priorities and there is a lack of clarity on who is handling what and when. GIST is lightweight, it is a single source that is flexible in a way that traditional road-mapping and adjusted project planning isn’t. Everyone can get a helicopter view of what each team is working on very quickly by checking out their GIST idea banks, and with more access to information and greater cross disciplinary transparency comes a decreased need for all those meetings to “coordinate” efforts.

When To Use GIST

The GIST framework grows in value the more mature the project

One thing that is important to note is that the GIST framework tends to grow in value as the project matures. Early on confidence in a team’s decision making is always going to be driven by personal experiences, historical data, and market trends. Since you don’t have anything to test really you can’t have medium to high confidence evidence. That said, your game might be a sequel to another game, a fast follower, or a time-tested genre that you are applying a simple innovation to. In these cases, you can at least have medium to medium-low confidence in many of your decisions even at the preproduction stage. The key will be to adopt a lean build measure and learn feedback loop. Get started on those grey box prototypes and interactive UI mockups so you can get some data and start having higher confidence in your decisions.

You should try to adopt GIST early

My point is, you should probably adopt GIST early. Ideally, start pre-production with the idea of using GIST in mind. I don’t think it would be healthy to shut down some of the creativity of the initial ideation phases of pre-production by demanding everyone ICE score their ideas, but it might help in the late stages to manage scope (even if confidence is going to be low overall). I mean we all know what a beast scope creep can be.

You can still migrate over to GIST late in production

You can also migrate over to using GIST later in the development process. As I’ve stated, GIST’s value is really being maximized late in the development process when you are actively testing a lot of more polished experiences, and during live ops on a game when you are getting a lot of data in real-time that can help you drive decision making. GIST easily plugs in with Scrum and Kanban. The first project I used GIST on, we used traditional Agile with Scrum until beta release when we became aware of GIST. We did have some problems with decision making being driven a lot by anecdotal evidence and gut reactions of some senior managers. When GIST came along and gave us a way to quantify and prioritize everything it was a chance we couldn’t pass up. We had fully integrated GIST into our process in only a few weeks, and it really helped us to focus our efforts. It also continued to be effective when we decided to move from Scrum to Kanban during live ops. 

GIST is probably best for mid to large teams.

GIST is probably better for medium to large teams. I’ll get into this a little later in this article, but many smaller teams don’t have a dedicated Producer or PM, and the work associated with GIST is probably best handled by someone whose job description includes owning all the production planning process. If you have to, you can spread the work around and mitigate the impact on any one team member. Though this will probably put a little more strain on your Leads and Product Owners. With a large team, you can do both, spread around some of the costing/scoring work, and have a dedicated individual owning and advocating for the process. This isn’t a law of project planning by any stretch. If you’re on a team of less than ten people, and still have a dedicated Producer (or are just super process-oriented) then GIST could still be a good fit for you.

Issues with GIST

GIST is “lightweight”, but lightweight is really in the eye of the beholder. It still requires a dedicated Product Manager or Producer to own the GIST framework and help organize the teams. Either that, or everyone has to make small but meaningful contributions and take ownership of their part. This can be problematic. A common structure for teams is to have Game Designers serve as Producers and/or Product Managers. If you add ICE scoring and idea bank management, along with coordinating goal setting, and quarterly step-project selection to an already full plate it might become a bit much for someone. However, it does replace a lot of often updated and hard-to-maintain processes like road-mapping. My point is, you need to be careful and clear about who will be responsible for the process ownership and being an advocate for the GIST framework (that might be the same person, it might be multiple people). 

Like any framework, you need to get buy-in from the whole team. You can’t have one department decide they don’t like using GIST and won’t adopt it, while everyone else is using it. Not only will this cause confusion: if you have to justify your decisions through confidence measures with clearly defined thresholds while another department can just “go with their gut” you might tend to resent them.

Finally, there aren’t as polished and sophisticated tools for using GIST. The Atlassians, Mondays, and Asanas of the world (to name a few) don’t have GIST workflows yet. Though, I imagine the lack of tools for GIST will change over the next few years as more companies realize its value. But, there are some pretty slick solutions for using roadmaps these days, like next gen projects in JIRA and roadmaps in ProductPlan. That said, there are still many people out there building gantt charts in excel, which just illustrates that you don’t need really sophisticated tools to use a framework.

TL;DR Summary

To sum it all up, GIST is a fairly lightweight framework with multiple planning horizons that puts a focus on evidence-driven decision making, over instinct and seniority. It plugs in nicely to existing Agile methodologies and encourages test-driven design and development. Will it automatically make you produce rainbow unicorns or the next Pokemon Go? I don’t know. Does it have the potential to make things a little easier for you? Very much so. Go check it out and see for yourself if it’s right for your project.

---

We hope you found this article helpful. If you have any tips of your own on how to implement GIST into a game development pipeline, let everyone know in the comments below. If you would like help instituting GIST or another framework, get in touch.