Version History

• 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.

Implemented Rules

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.

Tasks

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

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

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 Alchemists, 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.

Iterative Development

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:

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
• Blue+Red partially pass: Blue+Red, Red+Blue, Red+Yellow, Yellow+Blue 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:

1. 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)
2. 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
3. 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

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 integration.

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?

Victory Conditions

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.

Checkout

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 again.

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.

Rules (Video)

Rules (PDF)

... 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.