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)