I wanted to write more about how we're going to plan for the brainstorming session with the users for the rapid prototyping assessment.
For the brainstorming session, the participants will be asked to write as many stories as they can. We won't ask the user to prioritize the stories at the same time they are generating them; we'll ask them to do that later. The idea is to go from basic functionalities to high level interactions with the portal. The users brainstorm the things they may want to do at various points while using the portal. The idea is not to identify actual display fields, but conceptual flows and build the prototype up iteratively during the brainstorming session.
We will start with the main screen of the portal and ask them what they would like to do from there. The participants start throwing out ideas about what actions they'd like to take next. Each action is a new story (Ex: The user would like to search by an historical era, like the depression era). Ideally, we move from story to related story. For example: The user would like to search for images ----- the user would like to search for images from the depression era ---- the user would like to store the images in her account --- the user would like to edit the the images in her account -- the user would like to annotate the images in her account -- the user would like to share the annotated images with a colleague. The facilitator initiates a discussion of the details about each story to give to the developers.
As we walk through the prototype of the portal, we ask questions that help identify missing stories, such as (Cohn, Mike. User Stories Applied. Boston, MA, Addison-Wesley, 2004.):
• What would the user (you) want to do next?
• What mistakes could the user make here?
• What could confuse the user at this point?
• What additional information could the user need?
The moderator keeps a list of issues to come back to and pays attention as to which participant is contributing the story. If the participants include examples for acceptance testing, we include that information to pass on to the developers.
During the brainstorming session, the focus is on quantity rather than quality. There is no debate as to the value of each story so as not to discourage the participants from contributing the story. Open-ended questions are used to facilitate responses, such as "Tell me about how you'd like to search for an image".
Prioritizing the Stories:
If we have time within the allotted hour, we ask the users to prioritize the stories. If we run out of time, myself and the SWG will ask the users to prioritize the stories after the brainstorming session. Cohn's book recommends using the MoSCoW rules:
*Must have - fundamental to the portal
*Should have - important but we can use a workaround
*Could have - leave out if we run out of time
*Won't have this time - desired but for later iteration/grant
Then Chick, Tom and the SWG, the TWG and the MWG conference call/email/wiki and sort the stories by discussing their technical aspects. Can they be implemented with the software/algorithms/metadata we're using? Which stories impact other stories? Which stories apply to a broad base of users and which apply to a small number? How long will the story take to implement? What are the nonfunctional needs of the story (like performance)? Which stories are too small and can be combined? Which stories need to be combined because of dependencies? For the actual deliverable to the developers, I need to ask Tom and Chick what they need so that the stories and the details about the stories are useful to them.
Every two weeks we ask the participants to test the developments on the portal and give feedback to the developers (more on this later this week.)