You earn victory points in different categories but it is the points in your weakest category that determine the winner.
Code is represented by colored cubes and components by tiles with slots for input code and output code. The players take turns to perform one of the following tasks:
Program: Take code/s or exchange for victory points.
Model: Play one user story. The expected output is chosen by you and known to all players but the required input as per the user story is only known by you.
Develop: Play two input codes on another player’s user story.
If you fail, try again next turn. The other player gets codes equal to the color of the input.
If you pass, you get victory points equal to the color of the output.
Once a component is developed (i.e. both input and output is known), it becomes a component that can be integrated with other components and share code with each other so that the output of one component is used as input for other components. By integrating components in this way, you get victory points equal to the color of half the output. The bigger the module, the more victory points you earn.
The challenge of Find the Bug! - Agile is to find the right code for the right user story and plan your gameplay so that the code received from your current task can be used for the next task.
1.0: First edition
0.6: Product owner doesn't get codes at passed test, both codes and victory points are rewarded at integration, ability to switch colors at integration
0.5: Product owner does get codes at passed test but a code instead of a victory point at integration
0.4: Product owner doesn't get codes at passed test, ability to return test cases and end when depleted colors to prevent stalled games
0.3: Only tester gets VP at completed test, spent codes given to product owner, code exchange into VP
0.2: Component and stub integration, copy code from others
0.1: Tester and product owner share VP at completed test, component integration only, take codes from others
The complete rules are available in the PDF file to the right. In the following sections,
I will describe how they came to be.
Codes vs Victory Points
Many games have a time balance between resources (codes in this game) and victory points, where
turning resources into victory points early gives you less opportunities to victory points later.
The strategy is usually to build an economic engine and shift from resource production to victory
points production at the right time. In Find the Bug! Agile, this could have been accomplished
through the strategy create user stories -> get codes from other testers -> use
codes for own tests to earn victory points.
Another option is to focus on production balance, where a balanced production prevents resource
shortage. In Find the Bug! Agile, this could have been accomplished by setting up the strategy
create user story -> start a test -> switch between the two so that you earn and spend codes at an equal rate.
I decided to allow codes to be exchanged directly into victory pointes,
thus enabling both the product owner strategy (earn codes) and the tester strategy (earn victory points).
The two strategies will be discussed below.
The games tasks were selected to promote the general flow of the game: acquire codes,
use codes to create components, use codes to test components.
Pair programming has thre different options, all important to the gameplay.
Write: This is simply used to take one code from the repository and is necessary to add more code into play.
Copy: This not only adds a more thematic aspect but also serves as a small catch-up mechanism: a player with few codes
may get similar codes as a player with many codes (but not more than one of each color or else it would be a too
powerful way to earn codes).
Share: This creates the classic balance between resources and victory points; codes can be exchanged for
victory points but give less opportunities in the future.
Story-driven modeling is used to let the players create components for each other. This is not only
a prerequisite for the third task, Iterative development, but also gives the players the option to
choose the mix of codes both for their hands and for their boards. Will this output encourage testers and give me the
codes I need? Will this output add the component to the module and give me victory points?
An alternative would have been an app solution, similar to
to eliminate the need of players assuming game master roles. However, this would also eliminate
the option to make a strategic choice of output as discussed above. Unfortunately, this also
adds a risk of player errors, hence the penalty that the product loses codes
if he or she turns out to have chosen an invalid output.
The iterative development is used to let the players spend codes to earn victory points.
The choice of how to distribute codes
between tester and product owner at failed tests (codes to product owner) and passed tests (victory points
to tester) was made to create an asymmetry between the roles - should you go for product owner and earn
codes or tester and earn victory points?
The table below shows how the average distribution is fair to both players:
Before 1st test
Pass at 1st test
Pass at 2nd test
Pass at 3rd test
If tested properly, no more than three tests are necessary to find the right
combination. Take the example where the output is purple and green, leaving blue, red and yellow as
possible input. There are six possible combinations; Blue+Red, Blue+Yellow, Red+Yellow, Red+Blue,
Yellow+Blue and Yellow+Red.
Blue+Red fails: Blue+Red, Blue+Yellow and Yellow+Red eliminated
This gives the tester an average cost of 4.5 codes and the product owner an average gain of
0.5 codes from each completed test. Thus, the tester got 2 victory points more than the product
owner who got 5 codes more than the tester (which are worth 2.5 victory points if shared but at
time loss). A typical scenario could look like this:
Player 1 spends 2 codes on a user story, player 2 spends 2 codes to fail the test (and player 1 gets back her codes)
Player 1 spends her 2 gained codes on 1 victory point, player 2 spends 2 codes to pass the test and get 2 victory points
Player 1 spends her 2 of her own codes on 1 more victory point, player 2 spends her turn to write or copy and get some of her codes back.
The result is two balanced but completely different strategies, earning about 2 victory points
every third turn. This can be compared with the "free-riding" strategy of just copying and sharing codes.
Since copying only gives 1 code of each color, the player would have to spend a second turn to get a
second color and third turn to exchange a pair of codes into 1 victory point, earning less than 1 victory
point every second turn. This may be a good short-term strategy to complete sets of colors but not a
game-breaking long-term strategy.
Continuous integration is an advanced rule but also something that delivers something
"greater than the parts": the components integrated into a module. Adding an advanced rule that
significantly alters the strategy of the basic game is not a good idea so it is important to keep
the two strategies above balanced not only against each other but also against the third strategy of
The simulations above shows how the players get about 2 victory points every 3 turns. By giving
both 1 more victory point at integration to both the product owner and the tester, the strategies remain
balanced and give about 3 victory points every 3 turns. An integrator will be able to get 1-3 victory points
in a turn depending on how big the module is but also have to spend a turn in between to replenish codes so
again the strategies are balanced.
Why getting not only victory points but also codes back then? Simply to maintain the code balance.
The early phases of the game sees codes moving not only out of the game but also between players
(when testers "pay" product owners) but the later phase only sees codes moving out of the game
(when integrators test the module). To give all engaged players half of the codes to the hand
rather than as victory points, some codes remain in circulation and this prevents stalled games
where players have no other options but taking new codes. It also adds another decision element:
which color do I need in my hand and which do I need on my CV?
The endgame scoring of counting your "worst" color is more than just inspired by
Reiner Knizia's Tigris & Euphrates.
It also prevents "passive" strategies where you merely let other players score for you by creating
random user stories and test with whatever codes you get. You must actively seek a strategy that gives
you victory points of all colors.
In the inspirational game Master Mind, you are the only "tester" so a failed test can simply
be retried next turn. However, in a multi-player game like Find the Bug! Agile, there is an
obvious risk that the next players in turn will retest with more information before it's your turn
One way to prevent this would be to allow unlimited tests but that would require you to either
test with few codes on your hand (and risk running out of codes before you pass) or hoard codes
first (and forcing you to shift from a balanced hand to a specialized hand to pass and then back
to a mixed hand again). Given that taking risks is necessary to win, this would create a gameplay
where not the most strategic player but rather the most lucky player would win.
Instead, I introduced the checkout marker, letting you "keep" the test until you either pass or
decide to test something else.
How about the situation when you just passed a component test, just to see it snatched away
for another player's module test. This may create a waiting game, where players refrain from
completing a component test and wait for a more profitable module test. Again, the checkout marker
provided the solution by letting you keep the checkout marker on the component even after it
passed and forcing other players to either let you use it in a module test yourself or concede one
victory point if they use "your" component in a module test of your own.
... and Rejected Rules
There are of course also ideas that did not make it and here I explain why.
Take that programming
Maintaining a good mix of colors is important in the game so why not add
a take that mechanism where you replenish your hand from your opponents?
No, since maintaining a good mix of colors is important, why let a good color
management be so easily disturbed by the opponents? Also, it may just result in an
endless take back loop where the same critical color changes hands.
Hand size limit
To avoid hoarding of codes, I first had a hand size limit of six codes. However, the rules
about copying codes and sharing codes into victory points made the hand size self-regulating -
hoarding codes helps other players catch up and the game may end before you've capitalized on them.