Roger Evernden — Fri, 20 Jul 2007 09:31:17 GMT

Here’s another simple game to provoke discussion about the words we use and how we classify things. I started using this several years ago, and now use standard cards and materials that I have prepared in advance – but it can easily be adapted so that the players create the game pieces. I call the game Buckets (or Category Buckets).

List the categories and words that you want to analyse or discuss. Put each on a separate card. You will need two or three sets of these cards, depending on how many teams are participating in the game. I use a set of about 200 key words and phrases – the actual number will vary depending on the domain that you are exploring.

List any high-level categories that have been proposed. Write each one on an envelope or box (like a post box or voting box). I start with a set of 10 high-level categories, but again this can be expanded; if the domain has a large vocabulary, then you may want to introduce a hierarchy of categories that can be refined over several iterations of the game. Again, you need a set of these for each of the participating teams.

Teams now put the categories or words on the cards into the envelope with the high-level category that they think is appropriate.

Now the real fun starts. When all the words have been placed into their envelopes, teams compare and discuss their selections. This is where you find out nuances of meaning, different reasons for classifying in different ways, etc.

Roger Evernden

Roger Evernden — Mon, 18 Feb 2008 23:10:02 GMT

This has always been a difficult challenge – do you try to go with a single, consensus view of requirements or do you somehow try to be inclusive of everyone’s viewpoint?

I like Adam’s approach – it is systematic and a degree of objectivity.

I use a similar system – with weightings for priority, risk, value, and cost – but with a different process, which I’ll briefly explain here:

I use a hierarchy of viewpoints – starting from the views of individuals, moving up to the views of a team or group, the views of a business unit, project, product, or geography, and then to an enterprise-wide consensus view. The details of this hierarchy of viewpoints varies from client to client, or situation to situation.

When gathering requirements I assume that everything is a valid point, requirement, need, wish or observation. With each requirement I have a link to the originating viewpoint; for example, this could be an individual, or a team requirement from a workshop, or a mandatory enterprise-wide need. I also note the weightings for priority, risk, value and cost.

Comparing viewpoints uses a venn analysis to identify things that are common or not. This type of analysis allows me to highlight things that are common and move them into a viewpoint that is higher up the hierarchy. The higher a requirement goes up the hierarchy, the more it is the requirement of a larger number of people. (Note that this doesn’t necessarily mean it is better, more important or more valid).

It is a simple matter then of deciding which viewpoints are in scope for any phase of a project.

(There is more about this technique in my book, “Information First – Integrating Knowledge and Information Architecture for Business Advantage”)

Roger Evernden

Boxes and Arrows: Comments by Roger Evernden