Homework 4: Practice with User Stories


In Agile software development methodologies, we usually work closely with a client in order to define what the desired product will do for them.  That is, we spend some time in requirements definition early in the project (usually before the contract is written), although these requirements will be refined and expanded as the project evolves.  

From the client’s standpoint, they will be telling you what they want the software to do in specific situations and for particular groups of users.  They will be talking about functions that they want or a particular interface appearance. What they want it to do and how it will look. 

From the software developer’s standpoint, these are often called User Stories and are turned into specific features that will drive our behavior driven design process.  These can be formally entered into agile project management software products and used to calculate metrics for the project, generate project milestones, and create acceptance tests.

In Class Work

You will be roleplaying in pairs in order to complete this assignment.  Your job is to get some experience in talking to a (pretend) client, asking questions to elicit the components of a User Story and to get a clear picture of what the client wants so that you can document it in sufficient detail that you could program it. 

You will be (randomly) assigned a partner for a role playing exercise in which you and your partner will take turns being the client and being the software developer. 

When you are playing the client:

  1. Think of a piece of software that you would like to create or enhance. It could be your individual project.
  2. Think of two or three features that you would like to add or change and be prepared to describe them to your developer
  3. Think about what role you would be playing in relationship to the software you imagine.  Are you an administrator of a non-profit that needs to recruit volunteers? Are you a business person trying to sell a product online?  Who are you?
  4. Don’t make it too easy on the developer.  Try to describe these features in natural language from a layperson’s point of view.  (But don’t be impossible either.)

When you are playing the developer:

  1. Try to be conversational, as much as possible in a role playing exercise.  Ask questions and practice active listening techniques while you take notes. 
  2. Get enough detail so that you could write up a couple of User Stories that include:
    1. Their relationship to the software “As a movie fan …..”
    2. So they can accomplish what goal?
    3. What action do they want to take?
  3. Be prepared to make sketches or take notes on paper or notecards

What to Submit

Create a document that includes:

  1. Your name and that of your partner
  2. At least three user stories (see above format) that are detailed enough that you could code up these features. If you drew pictures/sketches of a user interface, please scan the image or take a picture of it (those phones are actually useful for school work!!) to include in the document.
  3. What active listening techniques did you try to use while talking to your “client”? Did you feel that this enhanced the conversation? Why or why not?

Upload this document into PioneerWeb.

Scoring (Rubric) (10 points possible)

  1. Roleplayed the developer
  2. Roleplayed the client
  3. Captured at least 3 user stories
  4. 3+ Point Of Views
  5. 3+ “so that ….” statements
  6. Context of what the project would do overall or what problem it is trying to solve
  7. Detailed enough that the user stories could be broken down into tasks
  8. Describes active listening techniques used
  9. Did the active listening techniques enhance the interview??
  10. Why or why not?
  11. Sketch of UI or components of the app desired (extra credit)
The views and opinions expressed on individual web pages are strictly those of their authors and are not official statements of Grinnell College. Copyright Statement.