This simple game is intended to help the players refocus their attention away from what functionality a software system might offer, and towards the value that can be gained from such functionality.  Agile software engineers place great importance on identifying routes to value through software development, so that the limited resources available can be targeted at the highest value features.  But for many beginning software engineers, the excitement of inventing new software features can overshadow the equally important question of which features are actually valuable.  This game helps teams of software engineers to think about the difference between what is possible and what is valuable, and to centre concerns about value when proposing new features for software systems.  We have also found it can encourage a more creative and adventurous approach to requirements discovery.

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 Abeer Shahid, Caroline Jay and Suzanne M. Embury, for our 3rd year elective UG course unit on Agile Software Engineering (COMP33711).