4B-User Stories --> Agile Requirements Gathering: User Stories& Estimation
User Story Format
-As a .. type of user, -I want to .. do something (a task), -So that (I can accomplish) .. some goal. (Ex: as a student, I want to add a class to my schedule so that I can graduate on time) (Ex: As a faculty member, I want to see what students are assigned to my courses so that I can plan for the rest of the year)
Some Task
-What is the user trying to do? the task that they are trying to form? -Or activity (Examples): --Login --Reset a password --Enter an order: this could be broken up into smaller tasks --create a new account
Persona
A persona is usually described as a fictional user (that represents an important group of users, or just 1) Includes a description of: -Perspective -Attributes of the users -Their goals (business related)
Epics
A user story that is too big -Usually multiple stories -Could be the "goal" in a user story. Must be broken up into "children" stories (or user tasks).
Acceptance Criteria
How will you "grade" the implemented user story? -How do we know it is done correctly? -Verify that a user's account name and password have been saved. -Verify that the password contains alpha, numeric, and special characters and is more than 8 characters long. should have AC for every single user story -want it to be as straightforward as possible -how will you test that functionality once its done to test if its working properly? ALL USER STORIES SHOULD HAVE A/C!
Agile Work Estimation: Poker Planning
Poker planning is a technique we can use to estimate the amount of work each user story will take. We use a unit of measure called a "story point." This is a made-up unit, like a "util".
Type of user
Some agile development shops will define specific user-types by using personas.
What is a User Story?
What: a description of a requested feature (or part of a feature) that is short and simple. A specific requirement for a new system/software. A sentence that tries to describe how a user would use a system--> something they want to do -focuses on who is the user and what are they trying to do (who and why)
Who:
Who: from the perspective of the person that would benefit from the feature.
Goal
Why does the user want to accomplish the task? Business related Example: -To place an order -To check on a delivery -To make a payment
Why:
Why: captures the "value" of the feature (to justify its existence) -trying to get idea of how valuable that task is compared to other features and functionalities that we identify for this system When: no time frame, but prioritized -wont specify a time frame, specify a work effort
Estimable:
clear enough that the developers can estimate the time/effort needs to be understandable and that everyone understands what it is
Negotiable:
is the starting point for communication and collaboration (not fully detailed) -user story is one sentence that defines a feature or functionality which means we have to flesh it out and add detail to explain what were talking about -trying to identify all the functionalities -negotiable means it can change
n Valuable:
more value, higher priority -try to come up with some value estimate for each user story
-Testable:
must be able to ensure it is working -acceptance criteria: some idea of how you would test the userstory /code for user story Ex: if you want to add a new customer, then you just look in database to see if theyre there -just wanna be able to check
Small:
should be able to complete within one sprint -needs to be the right size, small enough that a team of 10 people can complete it in 3 weeks (if thats the time frame)
Criteria for helping us write good user stories Independent:
should be implemented and tested as a unique element (function)