Peer Review of User Stories and Definitions
For this activity, your job is “grade” another team’s draft of their user stories and definitions.
Grading Each Story
Add a “Feedback” column to the stories spreadsheet under review, and go through each of the stories, adding comments in the column as per the following instructions.
For each user story, address each and every one of the following criteria. For any issues you find, add a comment with the corresponding letter code below along with a comment explaining the issue. Additionally, as you review each story, check any corresponding content in the definitions document, annotating the document with any feedback comments you have. In particular, watch out for definitions that unclear, incomplete, or really should be there, but aren’t. If you find that an issue repeats across many or all stories, you need not repeat the same comment over and over. Instead, simply mention it once in the global comments below.
- T: Title and description templates. Mark all USs that don’t follow the title and description templates provided in class.
- Example:
T: title has only a noun, and thus, does not follow the title template
- Example:
- S: Not too big. USs should be short and capture only one feature. Mark any USs with long descriptions or that are really describing multiple features (i.e., ones that are epics).
- Example:
S: captures a group of features and should be divided up into multiple stories
(include specific recommendations to clarify)
- Example:
- F: Functional user requirements. USs should contain only functional requirements (i.e., not non-functional ones) and be user facing. Mark any USs that violate this rule.
- Example:
F: this is a global usability requirement and is therefore non-functional
- Example:
- C: Customer-oriented. USs should not use terms and technologies unfamiliar to the customer. Mark all USs that violate this rule.
- Example:
C: AJAX is a technical term that the customer probably would not understand
- Example:
- R: No design, just requirements. USs should not inadvertently make design decisions. Thus, there should be no mention of implementation technologies or user interface buttons and widgets.
- Example:
R: dropdown box is a UI widget, and thus, a design decision
- Example:
- D: Uses the definitions document. The definitions document should be used to define domain-specific or application-specific terms. Mark any such terms that are used in the USs that are not defined in the definitions. You should also note if any definitions are extraneous or unhelpful.
- Example:
D: the parts that make up a movie record need to be defined
- Example:
- I: Followed other instructions. Mark any failures to follow other instructions that were given for this assignment.
- Example:
I: story ID does not follow the US1, US2, US3 naming convention
- Example:
- O: Other issues. Mark things like bugs/errors/typos in USs or USs that are redundant.
- Example:
O: seems to be the same as US7
- Example:
Overall Assessment
Once you have evaluated all the individual stories, create a separate document and provide the following overarching feedback.
- How well did the stories and definitions follow instructions? Select one of the following and explain your choice.
- Good/Excellent (perfect or nearly perfect)
- OK (some noticeable issues, but overall, still mostly followed instructions)
- Major issues (lots of very noticeable divergences from the instructions)
- How coherent were the stories and definitions overall? Select one of the following and explain your choice.
- Very coherent (everything was clear, understandable, and well thought out)
- Somewhat coherent (a few parts were confusing, inconsistent, redundant or poorly explained)
- Incoherent (lots of parts were confusing, inconsistent, redundant, or poorly explained)
- How complete did the stories and definitions seem? Select one of the following and explain your choice. If there are some examples of stories that you really would have expected to see but that were absent, mention them.
- Very complete (covered features very thoroughly)
- Somewhat complete (although a lot was covered, it seemed like some obviously needed features were missed; having a few epics may also be a problem here)
- Very incomplete (lots of clearly needed features were missing; having too many epics may also be a problem here)