This game is designed to get participants to think about how much of the features of common software packages are actually used, day-to-day. This leads on to a discussion of the value of implementing features that are used perhaps once or twice, by only a few users, across the lifetime of a software system, and from there to the YAGNI concept in agile development.

It is based around a software package that the people playing the game can reasonably be expected to be users of. Teams are given small cards with the names of menu items from the software package written on them. The team members have to categorise the menu items based on how often they have used the feature when using the software package: always, sometimes or never.

In the materials given here, we give cards with menu items selected from a version of the Thunderbird e-mail package. But it is possible to play the game with cards showing menu items from any software package.

Timing: 40 minutes in total, split into 4 sub-activities (15 mins, 10 mins, 5 mins, 10 mins)

Materials: Players should be grouped into teams, ideally of size 3-6.  Each team needs:

• A team sign.
• A role card.
• 10-15 copies of the feature sheet.
• A marker pen for each team member.
• Blu-tack/sellotape/pins to stick the feature sheets up on the walls/poster boards.
• If using the game as a connection activity, each team will need the instructions.

Teams will need a table or other surface to work on.

The room used must have clear walls on which feature sheets can be stuck, or room for poster boards to be put up around the sides of the room.  There must be enough space for players to walk freely around the edge of the room.

Instructions:

The game is split into 4 sub-activities:

1. In the first step, teams are asked to brainstorm features for a new software system.  The role card tells the teams what that system is.  It is important for success of the game that players are able to connect with the scope as possible future users of the system and not only as its developers; since our players are undergraduate students, we use an e-learning application.  Players write their ideas for features in the boxes on the feature sheets, and stick them up on the wall near their team sign.
2. In the next step, we ask players to circulate around the room and read the features proposed by other teams.  Players decide how much money they would pay for the feature as an in-app purchase, and write that amount in the space at the bottom of the feature sheet.  This could be anything from zero to hundreds of thousands, as the players see fit.  It doesn’t matter if some players don’t get to examine all the proposed features, and of course teams should not write money amounts on their own team’s features.
3. Players return to their own team’s feature sheets and tally up how much money other players were willing to pay for them.  The total amounts for each feature sheet are added up to give a total amount for the team as a whole. Each team reports their totals, and identifies their most and least popular features.
4. During the debrief, the teams discuss why they proposed the low value features, and what the high value features have in common. The game leader draws lessons about the importance of focussing on high value features, rather than implementing low value features just because they are there.  In the light of this discussion, teams are asked to improvise really valuable features based on the experience in the game.  Typically, the features proposed in this second round are much more creative, adventurous and useful than the ones proposed at the start of the game.

If there are a large number of teams, the game can optionally be run with two groups of teams. Each group of teams stick their features on separate walls, and are asked to write value amounts for features on the opposite wall. This prevents teams from giving value to their own features, without needing to police this.

Learning Points:

Beginning software engineers can often get fixated on simple CRUD-style features: upload assignments, create new course, add student to course, report on marks achieved so far, etc. These features make sense from a technical point of view, and may be needed, but they don’t in themselves provide much value for the user and they certainly don’t help to differentiate the product from the competitors’.

Asking players to explicitly think about how much money they would pay to use a feature helps to bring this message home.
The higher value features will be much more ambitious and creative, and more obviously linked to the user’s goal (to study more efficiently, to earn more marks for the same amount of study, for example).

When playing the game with our classes, we find that players will be far more innovative when proposing features in the final part of the activity than at the beginning. Examples of features we have seen proposed, for example, are: a feature to find suitable study partners, based on revision needs; a revision planner that works out how much time you should spend on each topic; and even an AI engine trained on marked solutions that can automatically grade attempts at practice papers.

This allows the game leader to start a discussion on how to find the features that will make the product great, by meeting real customer needs, rather than focussing on mundane features that everyone can build.

Credits:

This game was devised by Iliada Eleftheriou and Suzanne M. Embury, for our 3rd year elective UG course unit on Agile Software Engineering (COMP33711).