Exploring Requirements with a Wall of Wonder

Collaborate comes from the Latin words laborare (to work) and com (with), and so literally means to work together. Collaboration occurs when a group of people with a common and well-defined goal integrates their individual knowledge and skills to deliver on that goal.

In my work with teams, I often conduct collaborative workshops in which we create requirements and related deliverables such as stories, features, use cases, business rules, data models, mock-ups, product roadmaps, release and iteration plans. The workshops comprise a healthy mix of business people (users and customers or product owners) and IT (information technology) professionals, all driven by a single goal: to deliver the best software solution to meet a business need. The processes and techniques we use in these workshops contribute to building healthy team relationships, trust, and shared meaning.

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

Using the Wall of Wonder

Collaboration requires shared space in which the deliverables can emerge, and the simplest -- and cheapest -- form of shared space is a wall. Walls have been used by generations of human societies to record events and tell stories (this spans the entire range of human history, from cave paintings to modern graffiti), and to express hopes and wishes. The Wall of Wonder (WoW) is both a communication medium and a storage place for the tools and materials (which I’ll discuss below) and the content of the collaborative effort.

To make best use of the wall, groups need a structured process -- a fast, flexible way to leverage the wall space and engage in healthy interaction. Dynamics for healthy groups iterate around a well-recognized cycle first described by B.W. Tuckman (1) who labeled the phases forming, storming, norming, performing, and adjourning. Forming involves finding common goals and purpose. During the storming phase, members engage in open disagreement, which, under healthy circumstances, strengthens the group and promotes deeper understanding. Norming is the process of finding commonly acceptable ways for all group members to interact. In the performing phase, the group becomes task-oriented and focuses on producing the agreed-upon deliverables. The group’s dissolution is marked by the adjourning stage in which members close out their collaboration on the shared goal, including their role interdependency; this stage can engender celebration and genuine mourning.

Although you can't take shortcuts within this nonlinear set of dynamics if you want usable results, you can at least accelerate it. Certainly, a group that has worked together previously, and whose members are familiar with each other before the WoW session, may begin norming and performing right away. To produce a deliverable, however, they will still need to follow all the steps described below.

Storyboarding is one kind of wall work that follows the cycle Tuckman describes. A storyboard is a series of continuing panels, sketches, or scenes depicting a plot or sequence of actions. In business, storyboards are popular for solving problems and creating collaborative plans.

I based my Wall of Wonder approach on a storyboarding technique I learned from the Institute of Cultural Affairs (2). The group uses text or diagrams to build requirements, an iteration plan, or other important deliverables by successively using individual, subgroup, and whole group activities to generate items such as desired project features, business rules, use cases or user stories, data elements, screen navigations, and so on. I call it a Wall of Wonder (WoW) because of the wondrous results groups can achieve. Table 1 outlines the rationale for this approach, and Figure 1 shows a step-by-step flow. For a more detailed explanation of the steps, see my online resource detailing steps for facilitating a Wall of Wonder.

Table 1. Collaboration Pattern: Wall of Wonder (WoW)

Source: Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002. 

Figure 1: Wall of Wonder Process

At the beginning of each WoW activity, a neutral facilitator poses focus questions to trigger responses from participants. The focus questions vary, depending on the purpose. On the book page for my first book, Requirements by Collaboration, I provide example focus questions (scroll to the list of resources provided for Chapter 9).

After people generate detailed items on their own, subgroups write agreed-upon items on detail cards or sticky notes. Here's where the wall comes into play. You display these cards on the wall for the whole group to focus on. When everyone reaches agreement on the posted items, participants group the cards under header cards (usually in a contrasting color from the detail cards). At the end of the process, the group’s work displayed on a single, large wall.

Three Wall Strategies

In the bottom-up approach shown in Figure 1, participants begin with detailed items, and then work their way "up" to higher-level categories, designated with header cards. Along the way, they sort and eliminate items, such as product features, business rules, quality attributes, stories, story doneness criteria or tests, data elements, and so on.

In a top-down approach, participants prepare the header cards before the workshop or in an earlier collaborative activity. Starting with these broad categories, participants then work their way "down" by supplying lower-level details. This approach is useful when the categories are well known and accepted by participants ahead of time. Examples of high-level categories or header cards might be release dates, features, use cases or events, business rule sets, data entities or states.

In a middle-out approach, participants generate items more randomly, without regard to categories. Team members then sort the items, specify more detailed items, and converge on the categories. An example might be asking participants to list user stories during an iteration planning workshop on an agile project. After team members sort, combine, add, and clarify the cards, something that originally was posted as a user story may turn out to be a new feature, a story that is too large to fit into the iteration (e.g. and “epic” or “saga”), a story that belongs in another iteration (it doesn’t fit the iteration’s theme or goal), a story that needs to be partitioned into several dependent stories, or a story that is entirely out of scope.

Group Size and Balanced Participation

At a WoW session, your goal is to foster healthy group participation, achieving a state in which, as Aristotle put it, "The whole is more than the sum of its parts; the part is more than a fraction of the whole." There is a delicate balance between group size and getting the right participants ready to work the wall.

When a group includes people with different knowledge, perspectives, and backgrounds -- as is often the case in requirements workshops - then communication is complex. That is one reason subgroups are useful.

You'll want to form subgroups if you have more than four participants. This is critical for preparing for the "plenary" part of the process (Steps 3-6 in Figure 1). In later steps, the whole group reconvenes to model on the wall, working with potentially many elements.

I like to have subgroups with no more than three people; this small number allows them to get the work done quickly, encourages everyone to contribute, and discourages one-on-one conversations that can eat up time. Of course, dyads (groups of two) may be even faster, especially at the beginning of a workshop, because they allow the two people to get comfortable with each other. If you have more than six or eight people in your workshop, however, dyads may not be feasible.

WoW Warm-Ups

You can jump-start a requirements WoW session with a short imaging activity that helps participants concentrate on what will be important to put on the wall, and a brief mini-tutorial with an example, explaining the requirements' purpose. One essential warm-up is to use focus questions that direct participants' attention to specific items you want to get onto the wall. When the goal is to produce a requirements model, focus questions help direct the group's thinking toward an element of that model. They are also helpful to groups developing an iteration plan, defining a set of project risks, or specifying elements of a project vision.

To model the external entities on a context diagram (4), for example, you could ask, "Who or what provides information to or from the system?" or "Who or what must interact with the system?"

When you need to order elements in a model, your question can direct participants to a sequencing task -- for example, "In what order will a customer do these steps?"

Focus questions for requirements models can also build on some existing modeling element or project information. For example, if you have a list of user roles (actors) and want to create a list of use cases, you can ask, "What goals does the actor have when he interacts with the system?" Or, if you have defined use-case steps or user stories, and now want to define exceptions or test data, you can ask, "What can go wrong during this step?" or “how might this story not achieve it’s conditions of satisfaction”? These same questions are also useful to elicit business rules, because exceptions and erroneous test data are business rule violations.

Tools and Equipment for WoW Sessions

I prefer to use low-tech space for a WoW session because it's easy to change, it's dynamic, and frankly it's fun! Keeping your room visually rich and full of tools and materials invites creativity and change.

I equip the space with low-tech materials such as whiteboards, posters, butcher paper, sticky notes or cards, as well as tools such as colored markers. For the surface, I like to use a "sticky wall," which I create by covering two or three walls with poster roll paper that I've sprayed with repositional or remountable spray (available from 3M and other companies -- best to spray these rolls out of doors or where there's plenty of ventilation, then bring them inside to the WoW room). This makes a tacky surface to hold the cards (5X8 colored index cards work well) and lets you reposition them as you like.

Alternatively, I use 6x8 sticky notes (repositionable sticky sheets sold by Vis-It, Neuland, or 3M) on a flat wall. An easy way to document the wall's content is to take a digital photo. Note that a digital camera is an essential tool for quickly recording the groups work.

Visit my facilitation resources page to find links to some tools for working on walls.

In general, I don't like to use complex software during the session because it can reinforce tendencies to overanalyze and introduce unnecessary model elements. Projecting word processor content on the wall, on the other hand, can be useful -- especially for text-based deliverables such as use cases, user stories, business rules, lists of issues, decisions, and next steps. A person designated as the recorder can enter such text items in real time and project them on a laptop projector, or at least print and distribute them. This is especially efficient during walkthroughs, when the group reviews its work to detect defects.

In one recent workshop, we used both a laptop projector and a printer to great effect. In subgroups, business participants hand-wrote their requirements (in this case, data requirements, business rules, and business justifications) onto a paper template. Then, the documenter entered these into a laptop while the group took a break. The requirements generated by everyone were printed and projected onto the wall for a walkthrough. Instead of waiting to receive corrected documents after the session, the participants made corrections in real time and walked out with a set of requirements.

High-tech tools are useful in a WoW session for both documentation and requirements tracing; the key is to not make the tool the focus of attention.

In a recent iteration-planning workshop, the product owner printed out user stories from the product backlog onto half sheets of paper and arrayed them on the wall for the team to work with to plan the iteration. In another workshop, an analyst working apart from the group captured business rules in their requirements management tool. Team members were too busy working with cards on the wall -- building and testing their business rules with scenarios -- to worry about what the analyst was typing. He printed the rules from the tool in easy-to-read format so we could use them it to test these additional business rules in subgroups. In these examples, a requirements management tool (operated by another person, not the facilitator) can be helpful.

Nothing beats the speed and throughput of a same time/same place workshop that exploits the WoW approach. But a real-time WoW session also helps set the stage for continued collaboration when the team disperses. That's when automated tools really shine -- by keeping everyone informed about ongoing changes, by linking your requirements to other project elements such as releases, architectural and design models as needed and of course tests. That is, by tracing your requirements forward to development and implementation.

Engineering Collaboration into Your Work

Even with all our development tools and technologies, the process of building software still depends largely on the collaborative brainpower of the people who work on the project. The WoW is an effective technique for harnessing that brainpower. It fosters contributions from all individuals and provides a common place for creating emergent deliverables. By employing this simple, easy-to-use, repeatable way to build deliverables, you can accelerate your team's ability to collaborate, and begin engineering collaboration into the software development process.

Notes

1. B. W. Tuckman, B.W. and M.A. Jensen. 1977. “Stages of Small Group Development Revisited,” Group and Organizational Studies, Vol. 2, No. 4, pp. 419-427. In this revision, Tuckman and Jensen add the “adjourning” stage. Tuckman’s original article with did not include adjourning: "Developmental Sequence in Small Groups." The Psychological Bulletin, 1976, No. 63, 384-399.

2. See www.icaworld.org.

3. See "Decide How to Decide: A Collaboration Pattern" under Facilitated Workshops at http://ebgconsulting.com/articles.php#wkshp

4. A context diagram shows the system in its environment with external entities (i.e., people and systems) that provide and receive information or materials to and from the system. For more this analysis model and others, see: The Software Requirements Memory Jogger (Ellen Gottesdiener, GOAL/QPC, 2005).

This article was adapted from an earlier version I wrote for The Rational Edge.

Recommended Reading

Ambler, Scott, "The Practices of Agile Modeling," 2001. See "Display Models Publicly" at http://www.agilemodeling.com/practices.htm#DisplayModelsPublicly.

Cockburn, Alistair. “Information Radiator”, http://alistair.cockburn.us/index.php/Category:Information_radiator.

Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002.

Institute of Cultural Affairs, 1994. Group Facilitation Methods course guide, Institute of Cultural Affairs.

Katzenbach, J.R. and Douglas K. Smith, The Discipline of Teams: A Mindbook-Workbook for Delivering Small Group Performance. John Wiley and Sons, 2001.

Stanfield, Brian R, The Workshop Book: from Individual Creativity to Group Action. New Society Publishers, 2002.

Schrage, Michael D., Serious Play: How the World's Best Companies Simulate to Innovate. Harvard Business School Press, 1999.

Spencer, Laura, Winning Through Participation: Meeting the Challenge of Corporate Change with the Technology of Participation. Kendall/Hunt Publishing Co., 1989.

Zahinser, Richard A., "Design by Walking Around." Communications of the ACM, October 1993, pp. 115-123.

Copyright 2008 by EBG Consulting, Inc.

Author: Ellen Gottesdiener, Principal Consultant, , helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time. Her first book, Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her more recent book, The Software Requirements Memory Jogger is becoming the “go-to” industry guide for requirements good practices for business owners and analysts. Ellen’s company provides high value training, facilitation, and consulting services to agile and traditional teams. You can subscribe to her free monthly eNewsletter and visit the EBG Consulting web site for articles and other resources.