Using a Wiki to Organize Your Use Cases

Chaper 13 in Alistair Cockburn's book 'Writing Effective Use Cases' is just two pages long. But it is one of the most effective chapters in the book. In this chapter he talks about scaling up to many use cases and using tools to organize them.

• Say less about each use case: He argues that the use case name alone is useful. He says that the collection of use case names is an excellent working medium for manipulating the full set of use cases. This is true. We maintained all our use cases on a single wiki page and linked every use case heading to its own page. No big deal. But the list of use cases we had not written was highlighted in red and clearly indicated to everyone the status of the use case. It had not been written.
• Create clusters of use cases: We created a list of high level [Cloud level for those who know the Cockburn usecase hierarchy] use cases and then grouped the lower level [Sea level usecases in the Cockburn hierarchy] below them. This quickly gave us an idea of the high level use cases, the use cases below them and their status.
• Group Use Cases by Actor: We also grouped use cases by actors. We are building a learning system. So the actors were learners and administrators. This further clarified the use cases to the team.

Cockburn also says that the use cases can be grouped further by development team and release and by subject area. We have not gone there yet.

Mr. Cockburn talks about using Lotus Notes or spreadsheets to keep a list of use cases and cluster them. He wrote the book in 2001, when wikis were not popular. Probably that is why he did not mention the wiki.

However, it is is 2009 and Web 2.0 is here. We posted all the use case names in the wiki, clustered them by summary goals, and by actors and evolved the use cases over a period of a month and an intense one week design sessions where we uses the usecases as social objects for our discussion. Whn ever one of us was not clear about the discussion, it was possible to come back and ask the question, "Which use case are we talking about?".

While the team was discussing the product managers updated the use cases in the wiki with relevant details. The UI designer provided quick screen shots for inserting in the use cases.

At the end of each day's session the product managers sent the links to the updated use cases to the entire team. The development team added their comments, thoughts and questions in the wiki page. Since the product managers subscribed to the use cases wiki pages, product managers got instant updates of the questions, answers and confirmations.

After the first week of design sessions, the product team confirmed that the week has been very productive and the entire team had a good handle on the design. Not everything is done. But we know what we know and have a clear idea what we don't know. We know what we have done and what needs to be done.

If your product team is distributed, use a wiki to capture your use cases. It can be your secret weapon.

We use the Confluence Wiki to write our use cases.

I did not mention how our UI designer shared her screen using Adobe Connect so that all along the discussion everyone can watch the design morphing from conversation to onscreen elements. More about that later.