The Scoping Game at miniSPA2007
I ran the Scoping Game again at Monday’s miniSPA2007.
This is a simple ‘business’ game that introduces some of the issues in planning the Scope of a Software Product Line i.e. which products and products features to develop as part of your Product Line.
I didn’t count but I think I had 17 people divided into 5 teams - the unimaginatively named ‘Team A’, ‘Yodafone’, ‘Endeavour’, the also unimaginatively named ‘Front-Left’ and ‘SPAPhoneWarehouse’.
In the Scoping Game players take the role of stakeholders - managers, marketers, architects etc. in a fictional organisation about to embark on Software Product Line development. The players are given a fixed amount of cash and tasked with deciding which products to build from a set of candidate products, and which features those products should have.
To help them in this task the organisation’s Marketing group has provided estimates of the market value for each product and the Development group has provided estimates of the development cost of each feature. This includes estimates of how much it costs to develop the feature both as a reusable feature and as a product-specific feature.
Each team starts with the same information, resources and goals but the information is imperfect, for example, there’s some doubt about some of the predicted market values for some of the product features. What’s more the game is played in two rounds and there’s some uncertainty about which features will be needed in the second round which notionally takes place a year later in the company’s existence.
Given this the teams sometimes have to make a judgement call about which products and features to develop and this does result in different outcomes as shown in the picture below.
Yodafone took a narrow lead in Round 1 with their (unique) decision to develop the Starter Phone which no other team developed.
The game always raises issues about how mechanical the scoping process can be, what the business objectives should be (I typically use maximization of revenue when running the game) and whether the future can be predicted in sufficient detail to allow good decisions to be made.
The problem of course is that companies in a Software Product Line setting do have to have a good idea of their operating Scope and cannot simply say the future is hard to predict so we won’t try to. In a real-life setting your estimates will never be 100% accurate so you have to expect uncertainty. The question is how to quantify and manage this uncertainty through principles that maximize your future options - agile scoping if you like.
Here are some pictures of the event, courtesy of Andy Moorley again.
For posterity, Yodafone were the overall winners.
miniSPA2007 showcases six of the best sessions from the annual SPA conference. See here for my post on the Scoping Game session I ran at the SPA conference.




