Options:

Manon Penning

The Genius Toddler Challenge

How to create awareness for some of the difficulties requirements engineers face


“How hard can it be?” is a question posed by virtually everybody at one point or another regarding a line of work they are currently not involved in. We all know how hard it is to write sound requirements and user stories. Most people in our organizations however, are not aware of this and only criticize the current state of the requirements and stories. Not that their intentions are necessarily bad, mind you, they simply do not know or understand. Or at least, that was the case in companies I have seen so far. This effect is somewhat diminished in companies where Specification by Example or other collaborative techniques are in active use, but not obliterated.

While working for a large electronics company an opportunity presented itself at a team building day; there was an open slot in the agenda for that day. Traditionally this slot was to be used for in-depth presentations about roadmaps and the like. Instead, we convinced the manager to use it to address the awareness issue regarding how hard it can be to write quality requirements and user stories. A new game was born. Because this game was such a success within our department, we were requested to repeat the game for another department. Given experiences with the first instance, the concept was tweaked a bit left and right and has been applied several times since. What is the name of the game? Well, because of the discussions usually arising as to what are acceptable descriptions and what not, it was dubbed “The Genius Toddler Challenge”.

The basics

The concept behind The Genius Toddler Challenge is fairly straightforward. The participants should be divided into teams, each team consisting of two to six people. All teams will go through the two phases of the challenge. Based on the results of Phase 2 teams will be awarded points for their descriptions and their drawings as explained in the ‘Score card’ section.

Phase 1

Each team is given the assignment to write down a description of two simple, abstract images that are provided to them. These descriptions need to adhere to certain rules as described in the ‘Three simple rules’ section. This phase should be time-boxed at about ten minutes per image provided.

 The images provided can be any set of simple drawings made using a basic drawing tool.

For the original Genius Toddler Challenge images were used consisting of 3 lines. These lines are equal in dimensions, differently coloured. Each drawing has a unique arrangement of the lines.

Phase 2

The descriptions of each group are distributed to the other groups by the facilitator. Note that this requires duplication and coordinated distribution of the products of Phase 1. Each group is now requested to try to reconstruct the original images described. This phase should be time-boxed at about 5 minutes per description provided.

The process of the two phases is illustrated in Figure 1 for three teams (A, B and C) and with each team describing only one image. Note that it is advisable to have each team describe two images. How many descriptions are distributed to each team during Phase 2, is up to the facilitator. It can vary from two to the total number of descriptions created by other teams.

Phase 1 Break Phase 2
Figure 1: Illustration of the two phases of the Genius Toddler Challenge)

Three simple rules

There are a few simple rules that need to be adhered to during the challenge. The facilitator should explain these clearly before the start of Phase 1.

1. Descriptions shall be in basic-level English only

Of course drawing and sketching are not allowed and neither is using differently coloured pens for various parts of the description. Furthermore the words and sentences used should be comprehensible for a young child, say a bright or genius toddler (a child up to three years old). To give a couple of examples: Descriptions containing things like “parallel” and “right angle” are not allowed. Of course most kids at that age are not very proficient at reading, so assume the description will be read to them.

2. Each description shall not exceed the A5 provided, one-sided

Both for practical purposes (easier photocopying for Phase 2) and to prevent superfluous language usage. Besides, the attention span of a toddler for boring stuff is not very lengthy.

3. NO CHEATING!

Taking pictures of the images using phones or tablets and secretly distributing them to members of other teams (etc.) are not allowed. Yes, toddlers these days are very apt at using the swipe-and-tap technology, but the answer remains “no”.

Clarifying these rules usually leads to some laughter and people trying to find loopholes, especially when testers are present. Typically at least the boundaries of what language is allowed are challenged. Take into account that while a toddler may know what “half” is, other fractions are unlikely to be understood. A genius toddler may even know the (capital) letters of the alphabet, but that is about where the boundaries lie.

 Depending on the competences of the target audience, hints can be provided while explaining the rules. For instance the usage of metaphors can be encouraged as an alternative, e.g. “like the train rails” as an alternative for the word “parallel”.
Or on another track, the fact that all building blocks are the same length and width but only differ in colour can be presented as a given that need not be specified in the description. Adding onto that, the facilitator might even hint that the building blocks are like Mikado sticks (provided drawings like the example shown below are used). Thereby subtly planting the hint that maybe the stacking order matters.

It is advisable to take the exact placement of objects, as in relative to the borders of the paper but also as in orientation, out of the equation. This can be done either explicitly by announcing it or implicitly by taking it into account when judging the drawings produced in Phase 2.

An example

For the original Genius Toddler Challenge stick drawings were used. Each drawing was made up only of three lines arranged in a specific way. Not accidentally, the colours used were black, green, blue and red. These are the same colours typically found in any multi-colour (whiteboard) marker or pen set. Other colours can be used, but remember that each team should have the colours used handy for Phase 2. Of course you can devise your own simple abstract drawings, but keep them simple. Describing just three lines of given equal length and width proved complicated enough.

An example of a drawing that can be presented to one of the groups is shown in Figure 2. A possible description that adheres to the rules is provided along with it.

 Think of three sticks: A red one, a black one and a blue one.

Arrange them like the capital letter Z. The red stick is the top part of the Z. The black stick is the bottom part of the Z. The blue stick is the diagonal part in between.

The left end of the black stick is on top of the left end of the blue stick. The blue stick is on top of the red stick.

There is one tricky bit: The red stick needs to drop down towards the black stick, but stay behind the blue stick. That red stick should be a little closer to the lower end of the blue stick than to the higher end of the blue stick. Now the red stick and the black stick look a bit like the rails for a train, and the three sticks are not a real capital Z anymore.
Figure 2: Example abstract drawing – scaled down – with description

Score card

The teams are awarded points for both how well their descriptions are interpreted and for interpreting the drawings of other teams. It should be the objective of teams to make the description as clear as possible. On the other hand, the teams creating the drawing should be motivated to make the best drawing possible. Thus there needs to be a proper balance between the number of points awarded for describing and drawing, taking into account the number of descriptions each group makes versus the number of drawings they make.

It is possible for teams to receive a deduction of points because they violated one or more of the rules. The deducted amount is left to the imagination of the facilitator. It is up to the facilitator to judge the language used as either appropriate, or not. Other teams may file complaints and the facilitator should take those complaints into consideration and judge them as either justified or not justified.

Note that judging whether a drawing is correct may be somewhat subjective. In case stick figure drawings are used the stacking order may or may not be considered a critical factor. Rotating the image under a certain angle may be acceptable, but a mirror image is not. Also vague for the image shown in Figure 2 is the variance allowed in the distance between the black and the red line. So even the judging part is hard!
  • Make sure the drawings are printed on a heavier paper type or laminated with an extra layer behind it, so the see-through effect if held up to the light is minimized;

  • Prepare A5 (or comparable) description cards on which the groups can easily mark their group number and the drawing number or ones that already have these markings on them;

  • Distribute the drawings and description cards, including some scrap paper and/or additional description cards in a blind envelop only marked by the group number (and ask for everything to be returned that way too)

Evaluation and wrap-up

As mentioned when describing the score card, judging this challenge is to a certain degree subjective. Therefore it is important to address this in the evaluation and wrap-up. Usually, if the facilitator does not take the initiative to discuss this, one of the teams will. This is logical given that people are easily triggered to become competitive, especially when prizes (however small) are to be won or honour is to be defended. But that is a good thing, because remember why this challenge was created: To give more insight into what is so hard about requirements engineering.

To make a very explicit link between this challenge and the IREB curriculum, the facilitator could use the following passage from the IREB Foundation Syllabus [1] (p. 8):

“Typical symptoms of inadequate RE are missing and unclear requirements. Typical reasons for inadequate RE are:

Usually most (if not all) of this emerges during the challenge. Why do teams fail to produce the correct image in Phase 2? Because of missing and unclear “requirements”. What causes the “requirements” written in Phase 1 to end up like that? Well, maybe parts are overlooked or thought to be explained clearly enough, while having the original image at hand. A real-life customer may have an “image” in mind only. So compared to The Genius Toddler Challenge, a requirements engineer in the field has an even bigger challenge! And while one could argue that only being allowed to use toddler-level English is far-fetched, the language level used should at the very least be clear to all intended users. After all: Communication problems have been an inspiration for analysis for decades, see for instance the well-known Shannon–Weaver model developed in 1948 [2]. On top of that, customers, business analysts, developers, managers and testers (to name a few groups) rarely speak exactly the same elaborate language, which creates the need for some sort of common ground to fall back onto. So even when the official language used in your organization is not English, it could be argued that using English during this challenge simulates staying on that common ground. Lastly the strictly time-boxed execution of Phase 1 and 2, combined with the limited amount of paper to write the description on, in a way simulates the project pressure experienced in real-life.

In short, the facilitator can easily turn discussions that are likely to arise around. They can even be used to make your point(s) and wrap a nice bow ribbon around it. Because “How hard can it be?” A lot harder than it looks apparently! So far not once have all drawings been correct. Are you going to do any better?

For more information regarding the Genius Toddler challenge, for instance to be provided with the full set of original images or to receive information about a fully facilitated challenge, please send an email to: info@improveqs.nl.

References



Manon Penning

Manon Penning has a broad background in the fields of IT and education. She is an educational specialist, requirements engineer, quality analyst and trainer currently employed by Improve Quality Services, a provider of consultancy and training. Via Improve Quality Services she has been working for several Dutch companies over the past few years.