Passion for your project will come and go. Rely on a proven process to structure your chaos, and progress becomes inevitable.
3 months out from my Kickstarter, and since I’m planning right, there are a million things to do: playtests, promo art, manufacturer files, campaign pages, shipping quotes, and on and on it goes. Every day I’d stare at the list wondering what to tackle first, and more often than I’d like to admit, that indecision turned into paralysis.
So at a wits end, desperate for structure, I did something only a creator on the brink would do — I turned to the corporate world for help. Enter Agile.
If you’ve ever worked in product development, you’ve probably heard the word “Agile” thrown around. Popularized in software but adopted across industries, the intention of Agile is to make quick progress while being reactive to feedback. Now stick with me here, I’m not just trying to corporateate-ify your creative processes just for fun. I want to show how, with a few tweaks, Agile can bring surprising clarity to the chaos of game design and publishing. But first, a story!
The challenge: 20 sticks of spaghetti, one yard of tape, one yard of string, one marshmallow, and 18 minutes for team to build the tallest free-standing structure with the marshmallow on top. Who do you think would be most successful at this challenge? Engineers who can draft designs based on key structural principles to ensure a stable tower? Business school graduates who know how to organize a team, create a plan, and execute to perfection? You guessed it, it’s the kindergartners! Wait, what the heck? Yup, children are our future (of project management methodologies). Tom Wujec ran this challenge a bunch of times will all kinds of people and he presents his findings in a very interesting Ted Talk. What he found is that children approach the challenge with iterative trial-and error, building prototypes and refining the structures based on the immediate feedback of them failing. Adults/professionals on the other hand spend a significant amount of their 18 minutes deciding who is in charge and coming to a consensus on a plan before they start to build. They therefore end up panicking at the end of the 18 minutes to get their perfectly planned structure built in time and having no chance to iterate when it inevitably fails.
There are a lot of lessons that come out of this study, and it’s definitely worth diving into if you’re interested, but the main finding is that building fast and iterating based on feedback is the quickest and most efficient way to design something. You might’ve also heard of “failing fast“, this is the same idea. Before you invest too much time or resources going in the wrong direction check in with an early prototype to get that feedback.
If you follow any other board game designers, you’ll recognize that petitioning early feedback is very common advice. Especially in our space, it’s so common for a designer to go heads down on a game design for far too long before putting it in front of players and to see what is and isn’t working. The quicker you can correct issues and find the parts of the game that resonate with people, the better game you will have
So, pretty easy to understand idea – iterate quick and often to get feedback and make sure you’re on the right path to designing the best game. Now let’s bring this all back to where we started, because quick iterative feedback is exactly the intent of implementing Agile board game development.
How to use Agile for game development?
There are many different Agile methodologies and the implementation can depend a lot on the team and what and what they are trying to accomplish. Muddying the waters even more, in recent years Agile has become a corporate buzzword, making engineering leadership across industries want to stand up and proclaim “we’re doing Agile now.” I’ve worked in environments that claimed to be implementing Agile, but really it was Waterfall development where we planned things out in two week increments.
All this to be said, Agile is very complex and comes in a lot of forms. I will list out the core principles as My Agile Process for how I plan to actually use Agile to make progress and get good iterative feedback.
Let’s start with the key building block of the methodology – the sprint.
Sprints
Sprints are short time-boxed periods (usually 2 or 3 weeks long) where teams work to complete a chunk of work that was decided on at the beginning of the sprint. The goal is at the end of the sprint to have a “shippable” product that you can put in front of someone to get feedback on.
My Agile Process: I will start off using 2 week sprints, beginning on Wednesdays (weird but I found that works best for me). Since I am working on both designing and publishing tasks, what I will focus on “shipping” at the end of the sprint are deliverables that I want feedback on such as a draft Kickstarter sections, advertising art assets, rules, and meaningful game iterations. These will either be internal deliverables that feed into my feedback processes (such as new cards to playtest), or external deliverables (such as a draft Kickstarter page to share for feedback).
The work planned to be completed during a sprint comes from the Product Backlog and Sprint Backlog – which take those million tasks and prep them to get done.
Product Backlog
The Product Backlog represents the high level needs of your project. Needs like create a business plan, write the rulebook, create play reference cards, publish a Kickstarter pre-launch page, etc. The Product Backlog should be prioritized in some way to help you organize your work.
My Agile Process: I created a rough project plan of all the items I need to accomplish to get me to my Kickstarter launch. Not quite a full project Gantt chart (which would be used more in Waterfall style projects rather than Agile), I found it useful to sketch out which items gate others so I can prioritize the ones that need work early. While not the form of a standard prioritized backlog, I think this will do the trick for me.
Sprint Backlog
The next level of detail down, the Sprint Backlog should be specific tasks that you need to complete in order to accomplish higher level goals/needs in the Product Backlog. For example, you might break down my task above “Finished Card Design” down into sub tasks like find a font, figure out layout, design the card border, commission art, etc. The reason for this is that items in your Product Backlog likely take longer to complete than one sprint. If I’m working on the task “Finalize Card Design” for 2 months then I’m not gaining the benefit of Agile by doing quick iterations for fast feedback. Don’t start breaking down all of your Product Backlog items into a Sprint Backlog just yet, that is where Sprint Planning comes in.
My Agile Process: For an example of what my sprint backlog consists of, see the example sprint below.
Sprint Planning
The Agile process understands that you will be learning as you go and therefore modifying your tasks throughout the project. If you started by breaking down the whole Product Backlog into hundreds of items to form a huge Sprint Backlog, that is going to be a logistical nightmare with tons of rework when you inevitably have to rewrite half your tasks. Instead, before you start the next sprint, select your highest priority Product Backlog items, refine them to be clear what is needed, and then break them into discrete tasks. From here, estimate how much time each task will take and build a Sprint Backlog that will allow you to “ship” something for feedback at the end of the sprint.
In general, 20-25% of your sprint should be focused on addressing feedback gained from your last sprint, 65-75% should be focused on completing new items, and 5-10% should be on planning the next sprint. This is a good general breakdown, but allow these to change based on what you’re working on. For example, if you have a big playtest, maybe give yourself more time in your next sprint to address feedback from the playtest.
My Agile Process: Since I’m doing my publishing journey on nights and weekends, it’s harder to estimate how much free time I’ll have and how much I’ll be able to accomplish in a sprint. We’ll see how it goes but this might be a piece that I iterate on after I go through a few sprints, this would be something to be reviewed in Sprint Retrospectives
Sprint Review
The Sprint Review presents the completed work of the sprint to stakeholders to get feedback. This is the key feedback mechanism to see if you’re on the right path and make adjustments as needed. It’s important to consider who the proper stakeholders would be for the review as well. If you’re looking for feedback on your card art, find people who play a lot of card games, or graphic designers. Friends and family can be ok stakeholders for some reviews, but you run the risk of people trying to appease you rather than provide the hard feedback needed in Agile to effectively iterate.
My Agile Process: My Sprint Reviews will be performed with the most important stakeholders – you all! At the end of each sprint, I’ll share a summary post outlining what I completed, feedback I’m looking for, and what’s next. This will serve as both my public Sprint Review and an ongoing diary of my self-publishing journey. It keeps me accountable while letting you follow along and see what’s working (and what isn’t) in real time.
In addition to my Sprint Review post, I will also be getting more directed feedback for specific deliverables. I’ve started to collect a list of places I can go to find stakeholders for various types of deliverables.
- Game iterations – Local play test groups, Break My Game (BMG) for online playtesting, solo playtesting to determine balance
- Art – BGG, BGDL Facebook group, BMG feedback channels
- Page previews – BGDL Facebook group, BMG feedback channels, select friends I trust to give true feedback
Retrospective
After the Sprint Review and all other work in the sprint is complete, the Sprint Retrospective looks back at the processes followed in the sprint to see if any operating mechanics need to change for following sprints. It’s important all parts of Agile are open to feedback, even the Agile processes themselves.
My Agile process: I probably won’t formalize this too much, but if/when I make larger process changes I’ll check in so you can see why I changed processes and hopefully learn from my mistakes.
Real World Sprint Example (feel free to steal!)
Gather around my virtual board room table and let’s run through an example sprint. This is based on a sprint I did a while back and serves as a good example of how this all comes together.
As with every sprint, we start with a Sprint Planning session. For this session my highest priority Product Backlog item is publishing my Kickstarter Pre-Launch page so I can start sharing that and building my follower list. To break that down the individual tasks (also called user stories) would be:
- Create art assets for the landing page including, the cards, a basic set-up, splashy art, and a title.
- Submit for Kickstarter review – currently gated by getting my LLC paperwork approved, but that should be done within this sprint with enough time to complete this story
- Update my Kickstarter bio/profile
- Create a brief but engaging project description
The main “shippable” deliverable at the end of this sprint is my pre-launch that I could share for feedback. If I couldn’t complete all these tasks to get there this sprint, I’d still want to complete a Sprint Review to get feedback. In that case I’d select items to complete that would enable some level of review like some art assets.
However, looking at these stories I think not only is this doable, but I can actually complete a little more in this sprint. Since it’s related, I’m going to tag on completing my BGG Page. Not be my highest priority, but it goes nicely with my other tasks. For that, I have the following stories:
- Create art assets (likely very similar to the Kickstarter pre-launch page)
- Create description of the game
And because I’m writing this up and want to use this content to help other creators and selfishly generate more engagement I’ll add:
- Publish blog
- Post link to blog in BGDL
This means my Sprint Backlog for my first official sprint is:
- Create Kickstarter art assets for the landing page including, the cards, a basic set-up, splashy art, a title
- Create BGG art assets (if not covered above)
- Submit for Kickstarter review
- Update my Kickstarter bio/profile
- Create a brief but engaging project description
- Create a more detailed BGG game description
- Publish blog
- Post link to blog in BGDL
Now let’s fast forward two weeks to the Sprint Review!
I completed all of these stories except for submitting my game for a Kickstarter review. I ended up getting blocked due to a new issue arising that I couldn’t resolve in this sprint. The Kickstarter landing page was going to be my key output for this sprint, so I had to pivot. Agile!
Luckily not long after I was blocked I was listening to a BDGL podcasts where the Crowdfunding Nerds were explaining that for longer term crowd building it is better to drive people to an email sign-up landing page. So instead of completing my Kickstarter page I created a website landing page:
And I gave myself credit for another story
- Create website landing page for email capture.
I also shared the link to my site for feedback on the BGDL Facebook group to act as my “shippable” product to get feedback on. I got positive feedback, some good suggestions, and even some email sign-ups which was super exciting!
After my review I did my informal Sprint Retrospective to analyze how the two weeks went. Overall I found the approach very helpful to keep me productive and I ended up making a few changes to enhance it further:
- Sprint timing: I realized that ending on Sunday wasn’t great for me so I shifted Wednesdays.
- Sprint Backlog: The backlog was so nice for focus, but I found I was much less likely to do any task that isn’t specifically on backlog. That is of course part of the idea, so I’m glad that worked, but I found I could’ve used more smaller tasks in the backlog to fill small chunks of spare time. So going forward I’ll make sure to have more tiny tasks.
Takeaway: Even when blocked, having a sprint goal made it easy to pivot and still finish with a “shippable” deliverable.
I’ll be testing this process over the next few months so stay tuned. I’d also love to hear if you’ve found any processes that work for you stay productive. Do you prefer structured sprints or more freeform workflows?