An early rise on Day 2 of SPLC 2006 saw me in Salon B at 7:45 setting up for my tutorial on Software Product Line Scoping – The Scoping Game. I had 33 people registered so had asked SEI for some assistance to help run the session with this expanded group, and John Hunt, a student of John McGregor’s kindly offered to assist. I’d sent him the game rules and taken him through the game the previous evening so all was in place for a good session.

In the end we had 30 participants, including John. This was a good number that allowed for a wide range of questions and some variation in game play. By 8:35 all but a couple of participants had arrived so we got started. We began by reviewing the tutorial objectives:

• Understand Scoping and why it is an essential Product Line activity.

• Understand Scoping as an economic decision driven by business objectives and involving Scope trade-offs.

• Be able to identify stakeholders (and participants) in the Scoping activity and relate this to your own organisation.

• Understand the sources of information that underpin Scoping.

• Be aware of alternative Scoping approaches (and factors affecting the choice of approach).

• Understand Scoping as an iterative, on-going activity with a relationship to other Product Line activities.

• Know where to look for more information.

and then continued with a mixture of slides, simple class exercises and game-play of The Scoping Game. This is a game I invented to give people a chance to perform a simple Scoping exercise and thereby reinforce their learning through the session.

The Scoping Game places participants in a (fictional) software development organization embarking on a Software Product Line effort. Participants take on the role of stakeholders in the organization tasked with collaborating to create (and maintain) the Product Line Scope. Certain simplifications mean that no prior knowledge of Scoping or economic decision-making is required, other than that provided at the start of the tutorial, and so the Scoping Game can be used at the outset of an organization’s Product Line activities in order to familiarize their employees with this essential Product Line Engineering activity.

The participants were divided into groups of three. Some pictures of the game play will be available in my full conference report when I release that.

The game was played in two rounds. In round 1 participants played the role of product managers responsible for a single (mobile phone) product. Each player had to try and maximise the revenue for their own product. However, each team had to maximise the revenue for the team as a whole. The tension between these goals reflects real conflicts that can occur between stakeholders when launching and evolving Software Product Lines.

Revenue was earned for a product when all of its mandatory features had been bought by the team. Optional features could also be added, and this led to increased product revenue. Features could be bought either just for a single product or could be made reusable (at higher cost) for all products. Each player had a finite amount of money, so not every feature could be bought – players weren’t told this in advance and this led to an interesting aha moment during game-play.

In Round 2 the team was given its round 1 earnings and was asked to develop three further products. This time there was only a team goal, not an individual one. Furthermore, features that had been made reusable in Round 1 could count towards the new products so it was easier to develop the new products. (In fact, it turned out that I’d got the money slightly wrong and everything could be developed anyway which was a little disappointing for me and for the participants but this didn’t detract from the pedagogical element).

Aside from the glitch in round 2 the game was well-received and several people asked me for permission to use it in their training exercises. I’m still waiting for the full feedback analysis from SEI but the session as a whole also seems to have gone down well so hopefully I will be able to run it again some time in a refined form.

I have also collected all player-generated artefacts and will include pictures of these in the fuller report. One team even used a simple software spreadsheet to help them.

I will also include the final results in that report - there was quite a big deviation in earned revenue even though all teams were working with the same raw data and there was only a small random factor in revenue potential. This needs further analysis.

A full report, including this tutorial report, will appear on the Software Acumen website shortly.