A few months ago Catalyst was asked by a potential client to go through the project requirements with them in a workshop. There were about 120 requirements with the majority being “must have”, a few “should have” and a couple “could have”. The requirements themselves were mostly of a high level nature and thus providing them with an estimate that was not a ballpark was challenging. The workshop was to help us understand details of the requirements.

In this blog post I describe the idea that we implemented for the workshop, describe the material needed to run it and present its benefits. We ran this type of workshop for the first time and thus only have anecdotal evidence of its success. Nevertheless, I hope that it can serve as inspiration to you for re-thinking a similar session you are asked to run and try some of the ideas.

Coming up with an idea for the workshop

Since I heard the word “workshop”, I immediately went into workshop thinking mode. I did not want to have a session in which everyone was hunched over their multi-page 8-point font size printouts of the requirements spreadsheet or try finding the line item in the electronic document and waste time searching for items rather than discussing them.

Recently, I had also read the book Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo and was all excited not do run a “regular” meeting but incorporate more visual and engaging elements.

Thus, I took a fresh look at the requirements. They were categorized according to functional and non-functional areas and labeled “must have”, “should have”, and “could have”. We had also provided information on which functionalities Mahara, the open source software we were proposing for the project,

• had available out of the box;
• required only minimal configuration effort;
• needed some development effort whose scope was pretty well defined;
• would potentially need quite a bit of development effort depending on what the client envisaged.

Since the vast majority of the items were non-negotiable requirements, I decided to ignore that categorization. It was also of less importance to keep the topical categorization because we needed to look at the entire solution. Therefore, I focused on the third type of information, namely what the software could already provide and where we needed more information in order to determine whether development work was necessary and if so, how much that would be.

Focusing on the software and the elements already available would also help us show the organization how much they would already get by using Mahara as basis. Most of the time, an organization’s requirements are not a 100% match with any software and thus a minimum of customization is required. Identifying the particular items that would need to be customized is important and also having a good understanding of the effort needed in relation to the available budget in order to suggest functionality to start with and then expand on over time.

My expectations for the workshop

In preparation for the workshop, a colleague of mine in Australia and I had a teleconference to discuss what the organization wanted us to do, what we wanted to get out of the session, what information we had available and how much time we would have realistically. This session was very helpful to me in formulating the first ideas for the session and then ponder them over a weekend without the interruption of emails and other work.

The workshop would need to allow for the following:

• Engage all participants and not have them get stuck behind computer screens or lost in spreadsheets.
• Allow participants to get up and talk to each other right at the start.
• Encourage participants to draw ideas and work flows on a whiteboard spontaneously to support their ideas.
• Have the requirements that we are discussing present at all times and thus easily accessible.
• Make it very clear what we already know and where we need more information.
• Use our time wisely: Spend time only on the items for which we don’t have enough information rather than going through every single item. We probably had a maximum of 5 hours and most likely no possibility of extending the session due to the schedules of all the participants (there were nine from the organization and three from us).

I came up with a card-sorting idea that would take all these expectations into consideration and hopefully deliver.

Note: It can very well be that somebody else already described a similar activity in a book or online resource on facilitating meetings and workshops. I haven’t looked specifically for any. If such an activity already exists, please let me know in the comments.

The workshop objective

The objective of the workshop seems simple enough: Remind participants of all requirements, quickly deal with the requirements that only need clarification and then go over to discussing the requirements that need more information in order to understand them better and thus be able to estimate their development effort.

The workshop preparation

The preparation for the workshop consisted of a lot of copying and pasting, sorting of cards and making hand-written notes so as not to forget elements during the workshop.

Things needed

1. Project requirements
2. Template file that contains the cards as well as the headings
3. White 160g/m² paper
4. Four colors, one for each category
5. Printer
6. Cutting board
7. Post-it notes in one color that does not correspond to a category color
8. Highlighter in category colors (or approximations of them)
9. Sharpie and pen
10. Two differently colored voting dots (optional)

Set up the main categories

The four categories in which all requirements could be sorted are:

• Know / configure: Out of the box functionality, configuration, non-application requirements;
• Double-check: Some changes may be needed depending on the interpretation of the requirements;
• Clarify: Know what needs to be changed; no major analysis;
• Analyse more: Need for more information to understand the requirement.

Non-application requirements such as setting up of a hosting contract, offering user support fall under the “Know / configure” category as they are well-understood and part of the contract negotiation rather than software development.

These four categories are then laid out according to their increasing difficulty and receive a different color each. Initially, I thought of using differently colored paper, but I decided against it because none of the colors that were available went well together. Using white paper and printing color accents on them gives a much more professional look in my opinion. You can even use your brand colors if they lend themselves to it. I was lucky that our color palette allowed for such flexibility and thus I did not have to search for suitable color scheme.

Create the requirement cards

This is the part that takes the longest and is the most important. I transferred each requirement onto an A6-sized card and reviewed the category into which it fell. I also transferred any additional notes that we had already provided the client. Remember, I wanted to avoid that we needed to look up information in a spreadsheet and our proposal document. Therefore, all the information had to be readily available on each card.

You can download the LibreOffice Impress template. I set up each card on an A4 slide and then printed 4 slides on 1 piece of paper to get my desired card size. Only the category headings were printed as A4. All cards come out very nicely on 160g/m² paper because they are easy to grasp and don’t feel flimsy.

A4 paper with 4 cards on them

Here you can see the individual elements that went on a card. Due to confidentiality, I cannot show any of the original cards.

A sample requirements card

1. Provide the number of the requirement so it can be found easily in any document if needed, give it a short title and colorize the background according to the category into which this requirement falls.
2. Write the word “could” or “should” in this circle if this requirement is optional or use any other word that your client uses to identify additional functionalities that would be nice to have. You may need to shorten a phrase to one word.
3. Paste the full requirement in this box. If it is very long, adjust the font size. Everything needs to fit onto the front of the card.
4. If you provided a response to the requirement to the client in the proposal document, paste it in here. This is done in a slightly smaller font to set it apart from the actual requirement’s text.
5. If this item relates closely to another or is a duplicate, note this down here by mentioning the requirement’s number. This will help you group the requirements later more easily, though you don’t have to think about grouping yet. That is done later.

Transferring the information onto the cards also gave me the opportunity to think about questions that I might want to ask during the workshop for the cards in the “Clarify” and “Analyse more” categories.

Once I had transferred all requirements and additional information onto the cards and verified that they all had the correct category associated (represented by the colored bar), I printed and cut them giving me a nice little stack of cards to process further.

I jotted down my questions and comments on the back of cards for which I did not want to forget a question or additional comment during the workshop.

Group the cards

I now had all my cards and could start on grouping them into themes. These were partly themes taken from the requirements document or very loose themes only to help review the cards more quickly during the workshop. For example, I grouped all green cards relating to graphic design and all that dealt with support questions. I laid out all cards, took a Sharpie and my little post-it notes and went to task. I did not print out any little cards for this task because I wanted to be able to stick the notes to the cards easily and also make adjustments on the fly if needed.

Not all cards ended up in groups. I did not force the grouping but only used it where it was beneficial.

The following shows an approximation of what the cards looked like when we had them on the table at the beginning of the workshop.

The cards all categorized on the table

You can see that there are a few green and yellow cards in the “Analyse more” red group of cards. I decided to put them there so that they’d be together with the other requirements that were very close so they could all be discussed together.

The workshop itself

On the day of the workshop, my two colleagues and I arrived early so we could set up the meeting room for the card activity. It does take a bit of time to lay them all out. We also brought flip chart paper, flip chart and whiteboard markers, blue tag and voting dots along. Due to the room’s layout and size, we ended up not using the flip chart paper and only had a narrow walk way between the table and the whiteboard.

The workshop started with the usual introductions of the participants and the aim of the session. After we had outlined the idea for the workshop to all participants, they were game for it and we started right away. As we were informed of the time constraints of some of the participants, we made a couple of adjustments to our plan and left out the voting of requirements which I’ll explain as an option later.

We asked all participants to stand up and take a look at the requirements and their categorization. This was to familiarize them with the requirements again and put cards into a different category if we happened to have them categorized incorrectly. This wasn’t the case though and we could move on to the next phase after about 10-15 minutes. This phase was not intended to re-read every single requirement, but to just get an overview again and take in the requirements that were grouped differently now.

We confirmed that we did not need to discuss the cards in green in the category “Know / configure”, and we could put them aside. Initially, we left them on the table, but during a short break, I put them all on a pile to have more space available on the table. This also had the nice side effect that the participants could see how many requirements were already fulfilled in the size of the stack.

Size comparison of the requirements

We went quickly on to the cards in the category “Double-check” and could deal with them within a few minutes as we only needed to double-check with the workshop participants that we understood the requirements correctly. Where no additional work was needed, I took a highlighter pen and marked the card green. I also noted down the result of the discussion on the card itself. We did the same with the cards in the category “Clarify”.

This now left the rest of the workshop to focus on the cards in “Analyse more”. Initially, I had wanted the participants to rank the cards so that we could discuss them according to their priorities. Everyone would have received five voting dots that they could have distributed onto the cards. The cards with the most votes would have been discussed first. For the end of the workshop I had envisaged participants receiving a second set of voting dots in a different color and voting on the cards again now knowing more about the functionality and maybe revising their priority.

However, since I had grouped the cards already, we had reduced the number of topics. Furthermore, one of the participants had to leave early and thus we discussed the topics that were of most interest to him first.

We reviewed each group of cards and discussed their functionalities, what the participants expected of them, why they were important, what work flows they envisaged and where it fit into their program. This was not a detailed review of the functionalities, but did go deeper than the line items in the requirements document and gave us good insight into the reasons for wanting the functionality and what the workshop participants tried to solve. The discussion also gave the participants the opportunity to discuss their ideas further with their colleagues under some different guiding questions and looking at their initial ideas in a new light.

As I was facilitating the workshop, one of my colleagues offered to take notes. This is very important so as not to lose information and also to be able to consolidate the information from the cards with the notes later on.

We finished reviewing all requirements satisfactorily in just about three hours and everybody left on a high note knowing that their opinions had been heard, discussed and that we had focused on the important ideas that needed discussing instead of blindly going through the requirements catalog from beginning to end.

A couple of participants remarked explicitly that they enjoyed this workshop and that going through requirements had never been as much fun before. One of them also wanted to trial this idea in the future. Needless to say that I beamed for pride and was very happy that I had achieved what I had hoped to accomplish with this session.

Take note

There are a few things that you should be aware of to avoid last-minute panic. Some things may be more out of your control than others and you’ll have to make the best out of what you have available. Improvisation is after all an important part of the job.

• Venue: If you have the chance, check with the meeting organizer that you have a room available with a big enough table, whiteboard, projection screen, Internet access and also enough room for the participants to navigate. Our room was fairly small with a table that was too large for the room thus making it difficult for people to move. There was a big TV available as projection screen, but it took a bit to figure out how to log in.
• Review the cards: Have your cards ready at least one day in advance and go over them with a colleague who’s attending the meeting as well. You might spot a card that has the wrong category color or is missing information.
• Last-minute changes: If you do need to make changes to your cards, know where you can print them if you can’t do so in your office. Our workshop didn’t take place near one of our offices and thus printing changed cards proved to be more difficult.
• Bring all your supplies: This is a no-brainer for most people, but should still be taken into consideration especially if you do not facilitate workshops often. Bring all the supplies that you need so you know you have everything and don’t depend on the venue. Whiteboard markers tend not to work if there are any available and usually flip chart paper is also nowhere to be seen when needed. Also take along extra white cards in case a new requirement pops up and needs to be added. Also have the requirements and proposal documents available electronically.

Benefits

The benefits of running the workshop as I did were clear to me during the session and also afterwards:

• All participants were engaged the entire time.
• Nobody got lost in requirements documents, but had all necessary information in front of them on the table.
• Participants saw visually how many of their requirements were already fulfilled and how few only needed to be discussed.
• We stayed on track during our discussions as we knew exactly what we had already accomplished and what we still had ahead of us.
• We finished early because we didn’t spend precious time discussing items that didn’t need attention.

If you think this idea might work for a workshop that you are facilitating, please give it a try and let me know how things go and what changes you made. I’d be interested to learn if it works for others as well.

Update: A slightly less “stream of consciousness” version can be found on the Catalyst blog.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.