This game is part of my course on Software Quality which deals mainly with the following subjects:

• testing in all its guises, particularly unit testing,
• tools for measuring and helping improve software quality: PMD, Findbugs, Coverage analysis, documentation, code structure, coding conventions, design rules...
• tools for improving and streamlining the software development process: IDE (Eclipse), SCM (Subversion), build management (maven), defect tracking (Trac)...

This particular game departs from standard XHour rules on the following:

• the objective is to build, in one hour, a base camp for robotized exploration of Mars surface, with support buildings for human colonization,
• the base is built with Lego cubes
• there are two developer teams, each with 3 developers and 2 testers (initially) and with its own Lego box,
• there is one moderator to keep things rolling and ruling out debates over precise meaning or intents,
• there are two customers.

The time frame is standard:

• 10 min. for initial stories and architectural spike where only 2 "architects" work but everybody can comment,
• 10 min. initial estimates by developers and prioritization by customers, testers think of acceptance testing for stories,
• 10 min. iteration planning with developers defining velocity and splitting stories between the two teams,
• 10 min. building: customers write new stories, developers build, tester write tests and pass them against what developers build,
• 10 min. feedback and second iteration planning,
• 10 min. second iteration building,
• final release decision.

The game took place in a standard class room with tables and chairs arranged for allowing developers, testers and customers enough private space.  

After some initial explanations, I distributed at random the roles to prevent usual affinity groupings to occur. We then proceeded to the game itself.  

Initial stories  

The two customers went on writing stories on regular 3x5 cards, while one developer from each team started building some elements with Legos. There was not very much interaction with the customers at that time, and other people mostly wandered around the two "architects".  

Here are the two customers writing their stories:

And here are the architects at work:

with some wandering and noise from other students

Estimating (and planning)

The second and third sequence were actually somewhat merged to keep everybody busy (see below). Everybody took part in those phases, with an emphasis for the testers on trying to devise meaningful tests from whatever the customers where asking:  

The stories were then classified and estimated, giving the following tasks in descending order of priority (third column is team assignment):

This account for 27 minutes worth of work, for a theoretical maximum effort of 60 minutes (6 developers x 10 min iteration), or a little less than 50% focus factor. This is not overcommitting for a standard running project, but may be quite optimistic for an initial run. Note also that the estimates are not widely spread: Everything take either 5 or 1 minute to build !

Building  

Then each team started building while testers were writing and passing tests and customers new stories.

Team 1

Here is team 1 produced building at end of iteration. The building is supposed to be the armory:

Interestingly, the testers were the sole participant to interacts with the customers, asking for detailed requirements and precise meanings of stories. For the base, they came up with the following "tests":

• base must have strictly 2 entrances (no position nor size given),
• the fence must be 3 to 4 "meters" high (*a meter is one lego block),
• there must be one robot guard at each gate,
• the base's surface must be at least 40 "square spikes" (a lego's spike).

Although they were not quite precise tests, the lack of communication between testers and developers lead to them not passing: The fence's height requirement is not obviously met. Moreover, the testers did not have enough time left to write hence pass all the tests !

For the armory, the acceptance tests were:

• 1 shielded door (no description),
• 1 window with lattices (size ?, position ?),
• a storage cupboard (size ?, position ?),
• enough room for 20 people (ie. 20 spikes).

They were not met either, the armory lacking any window and not being finished by developer's account.

So net deliverable result for team 1 was: 0.  

Team 2  

Team 2 did not fare better in this iteration. Here is the bunker at mid-iteration:  

The testers were somewhat more precise for team 2 and gave the following tests for the bunker:

• bunker must have 3 shielded doors,
• 4 walls,
• each wall must be two spikes width and 6 blocks height,
• 1 roof,
• bunker must be buried,
• surface must be between 40 and 80 spikes,
• bunker must resist a hit by a (full) pencil case.

The control tower tests were:

• it must be located between 1 and 2 kms from the base (how does this translate in context ?),
• must contain between 1 and 3 persons (the team, where ? how ?),
• it must be possible to see all landing tracks from its top,
• one door,
• one lift.

Result for team 2 is then: 0.