Brainstorming – Making Something Out of Everything

Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps).

Seven to ten people is a good number to pull together in a brainstorming session. With creative and vocal people, a smaller number can work.

Five Steps to making brainstorming effective

1. Set the ground rules. Let people know that this is a brainstorming session, which means that all ideas are valuable. They may be bad ideas, but they can lead to good ideas. The most important thing to make sure people don’t do is criticize any ideas. People need to feel no fear – this is a creative release and they need to feel secure that any ideas they throw out are for the good of the cause. I have run brainstorming sessions where people have felt inhibited by their managers who might think an idea is stupid. Unless we know that this won’t be the case, we should exclude managers from the sessions, and try and fill the room with peers.
2. Set a time limit. There have been studies that show that creative thought is more effective when there’s a time limit. Creating Passionate Users has a post titled Creativity on Speed, where this idea is pursued in interesting ways, including creativity deathmatches. Makes for a nice segue. Set a 20 minute time limit on the session – long enough to get some juices flowing, but short enough that people won’t feel like it’s a waste of time.
3. Define a starting point. We don’t want people coming up with ideas for space elevators or edible plates – we need some focus. Since we’re eliciting requirements for a specific product, we have a context. Identify the high level goals of the business for this project, and write them on the whiteboard (or flip-chart paper taped to the wall) before the meeting. People will read this during the setup and subconciously start thinking of ideas. A statement like “Acme Bricks and Mortar needs a website to sell directly to customers online.”
4. Shout out and write. This is the fun part. Everyone in the room shares ideas as they come to them. Write them all down. Don’t editorialize the ideas. Some ideas will be requirements like “Make the borders of the page look like bricks” and others will be ideas like “90% of our sales is to existing customers.” Write it all down. If the group is too raucus, get a second person writing down ideas. Sometimes we end up with a room of people who aren’t comfortable, or aren’t interested in getting started. Start throwing out some ideas – say them out loud and write them down at the same time. If we don’t have strong relationships with the participants, this could easily backfire – we could cool off the room we’re trying to heat it up. An alternative is to start asking questions – “what do people care about when buying mortar online” or “what else do people buy when they buy bricks?” Think about some starter questions before the meeting. Don’t try and cram all the ideas together into nice organized lists – just write them wherever is convenient, this isn’t the time for structure. Prioritize quantity over quality at this point.
5. Pick the best requirements. The most important requirements are determined by the group, as described in the next 5 steps.

Five steps to picking the best requirements

1. Flag the requirements that should be considered (all of the requirements, but none of the thought-fragments, goals or general ideas) with a star or a colored post it note. If we’ve done this right, we will have several sheets of flip-chart paper or whiteboards covered in requirements, ideas, words and fragments (maybe even pictures). Tape the flip-chart paper on the walls if that’s where the ideas are written.
2. Count the requirements. We’re going to create three evenly sized priority buckets and place the requirements in the buckets (1,2,3). Each person will rate every requirement as a 1,2 or 3 (1 being most important). Give each person a stack of post it notes and a marker, and have them make out a fixed number of 1,2, and 3 post-its (evenly divided, with the remainder as 2s). It’s important that people be forced to divide the scoring evenly so that they don’t make every requirement a 1.
3. Everyone prioritizes the requirements. Have everyone physically get up, mill about, and stick their post-it-note priorities on all of the requirements. The scoring is somewhat subjective and individual. Provide a guidance about how ideas should be rated (value, feasibility, alignment with strategy), but ultimately each person will make a judgement call, and that’s ok.
4. Tally the scores. Add up all the scores, and pick the requirements with the highest priority (lowest totals). Throw all the scores in a spreadsheet – and look at a quick X-Y graph. It’s the weirdest thing – there always seems to be a cluster of scores for “important requirements” and then the rest of the requirements sort of taper off. There’s probably a mathematical reason for it, but someone smarter than I will have to explain it to us. The requirements in the top-cluster (probably between 1/4 and 1/3 of the ones we just scored) are the “first cut” requirements.
5. Make a list of the first cut requirements. We’re not done, however. There is usually at least one really good idea that didn’t fall in the top cluster because the “group” didn’t all agree that it was important. Give everyone in the room a chance to nominate one of the leftover requirements into the first cut group. Let them make a case for it. If we see something that we suspect is valuable, ask questions about it. Pull these ideas into the list.

We don’t have a spec. Yet.Brainstorming isn’t the key to writing a requirements document. There’s a reason that design by committee and group think make us cringe – because nothing great comes (solely) of it. A brainstorming session gets us a starting point when we are faced with customers who “don’t know what they want.” Even people who don’t know what they want generally have a good idea about what they don’t want. It’s easy to be a critic. Use this first cut list of requirements as a starting point. Review the list in individual interviews. Understand the ROI of these ideas, validate their strategic alignment with the stakeholders. Having a concrete set of requirements is the easiest way to get someone to say “We don’t need that, what we need is this!”Use the results of the brainstorming session to seed the cloud of ideas in one-on-one interviews. Don’t just spell-check them and hand them over to the dev team for implementation.- – -20060131: I just found this great link to some other brainstorming techniques at Never Work Alone -> Brainstorming 101. Check them out