Your team must gather all the functional requirements for your app and specify them as user stories.
As your team comes up with user stories, you must enter them into your backlog document.
Required Features to Cover. Your team’s set of user stories must cover all of the following features:
Customer-facing features
Browsing item listings
Search/sort/filter item listings
Manage cart
Check out and complete purchase
Review purchase history
Vendor-facing features
Manage item listings
Manage item inventory
Non-trivial niche-specific features
Expect a Lot of Stories. Each item above likely suggests multiple user stories. You will likely have a lot of user stories (over 25) — that is to be expected.
No User-Login Stories. Notice that user sign-in/sign-up/sign-out features are not mentioned above — do not make user stories for them.
Additional Features Expected. It is expected that the team will also have stories for features that go beyond the ones listed above.
Everyone Must Contribute. All team members must contribute to the effort to conceive of and document these requirements.
Story Formatting: Your team’s user stories must be specified and formatted as follows:
Story ID:
The ID must be of the form US01, US02, US03, etc.
Each user story must have a unique ID.
Don’t change a US’s ID once an ID has been assigned (for fear of introducing errors).
Don’t worry about sorting user stories in order by ID or about gaps in ID numbering.
Story Title: The title must follow the VERB NOUN template discussed in class.
Story Description: The description must follow the As a WHO, I want WHAT so that WHY template discussed in class.
Customer Oriented. Stories do not include technical jargon or other terms that the customer would not understand.
Requirements Only. Stories are free from inadvertent design or implementation decisions (e.g., does not mention UI widgets).
Short and Sweet. Each story is no longer than a sentence or two and captures only one feature (not a group of related features).
Grading Rubric
There are two categories of evaluation criteria for the user stories: quality and quantity.
Quality Criteria:
Each user story should meet the following quality criteria.
Valid and not redundant.
Clear and understandable.
Follows the title template - VERB NOUN.
Follows the description template - As a WHO, I want WHAT, so that WHY.
Specifies only functional requirements (not non-functional requirements).
Customer oriented (e.g., do not contain technical jargon).
Free from inadvertent design or implementation decisions (e.g., do not mention UI widgets).
Short and captures only one feature (not a group of related features).
To assess the overall quality of a set of user stories, the percentage of stories that satisfy all of the above criteria will be calculated.
Quantity Criteria:
Required Features. Your team’s set of user stories must cover all of the following features:
Customer-facing features
Browsing item listings
Search/sort/filter item listings
Manage cart
Check out and complete purchase
Review purchase history
Vendor-facing features
Manage item listings
Manage item inventory
Non-trivial niche-specific features
Inspecting the set of user stories your team has written, the instructor will assess how completely the set covers the expected requirements for the app.
Quantity Ratings. Based on the instructor’s assessment, they will rate the set of stories as follows:
Complete - No noticeable omissions.
Minor Deficiency - A few key stories omitted (no more than 4 key stories omitted).
Major Deficiency - A substantial number of stories omitted (more than 4 key stories omitted).
Grade Requirements. Minimum requirements to earn each grade: