Nuggets of Wisdom: The fastest way to build something is through quick iterations and feedback, not long detailed planning and execution phases.
Discussion Question: Do you think applying Agile board game development to your design/publishing process would be useful?
If you’ve ever been exposed to product development you’ve likely heard the word “Agile” being thrown around. Popularized in software development but adopted by project management in many different disciplines, 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 corporateatize your processes just for fun. I want to share why, based on my professional experience in product development, I think Agile board game development can be implemented into your processes to improve your outputs and help organize all the madness that is designing 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.
What is Agile Board 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. So without getting into the weeds, let’s look at the core principles of Agile focused around 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 Mondays. 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.
The work planned to be completed during a sprint comes from the Product Backlog and Sprint Backlog
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 Background 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.
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: I’ve started to get a good 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 for feedback, even the Agile processes themselves.
My Agile process: I probably won’t formalize this too much, but I will post what I complete in my diary on this site and probably in my BMG diary. 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.
Example Agile Board Game Development
Gather around my virtual board room table and lets have a Sprint Planning session to kick off our Agile board game development. Right now my highest priority Product Backlog item is to publish my Kickstarter Pre-Launch page so I can start sharing that to build my email 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, 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
At the end of this sprint the plan would be to have the pre-launch page published that I could show to my stakeholders to get feedback and then iterate on in the next sprint. If I took a look at these tasks I decided I wouldn’t be able to complete the page 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. I’d likely commit to completing the art assets and have people review those independently of the complete page, and then in the next sprint finish up the rest of the tasks to review the whole page.
However, looking at these stories I think I can actually complete a little more in this sprint. Since it’s mostly related I’m going to tag on completing my BGG Page. This might not be my highest priority, but it makes sense to do it in this sprint as I’m completing equivalent tasks. For this one I’d 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
- Link to blog in BMG diary
- 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
- Link to blog in BMG diary
- Post link to blog in BGDL
Let’s see how implementing Agile board game development goes and I’ll see you back here in two weeks for my Sprint Review and Retrospective.