Section 5
Resources
Definitions
User Stories
As a <user> (who), I want <what> so that <why> (Acceptance Criteria).
“As a Customer, I want to log in with my facebook profile so that I don’t have to remember multiple passwords.”
All Users Stories should have each of the following credentials: INVEST!
- Independent: Can be produced without dependencies on other items not yet completed.
- Negotiable:
- Valuable: Something the customer would be willing to pay for or would find important.
- If it is not Valuable, it should be a Task, Sub-task, or a Requirement
- Estimatable
- Sized Appropriately: No bigger/complex than necessary.
- Testable
Story Points:
A unit of measure that defines how difficult or complex a User Story is. This should something like 1, 3 or 5, or like t-shirt sizes: s, m, l, xl,, xxl. These ratings will be used to determine the project Velocity
Product Backlog:
An ordered list of all all User Stories required to complete the product or project.
Sprint Backlog:
The set of Product Backlog items selected to be delivered over a period of time (Sprint).
Velocity
The number of Story Points the team delivers over a Sprint. This will vary early in the project as you are ‘guessing’ how much the team can do, but will become more accurate over time by averaging the previous Velocities.
You can only determine the Velocity after a Sprint has completed once you have reviewed what you have delivered vs. what you had planned. it is not how much you planned to deliver, but how much you actually delivered in Story Points.
Swimlanes
A visual representation of Stories (Y axis) vs. status on the Agile/Kanban board: To Do, Doing, Done (X axis). Swimlanes let the team see progress on the individual stories, while highlighting specific areas that need attention.
MVP (Minimum Viable Product)
The bare minimum product that meets the client’s expectations. Includes all must haves and excludes all nice to haves (bells and whistles). This allows the team to deliver quickly and often and itterate and enhance your solution over time.
Release
When you move your User Stories to the Production environment (make them live). Generally, Agile teams make releases to production once a month (every 2 Sprints) but you might find some Agile teams releasing to production once every 4 Sprints. The Release schedule is for the Agile time to decide, but at the end of the day, Agile is about doing things efficiently and quickly, so the shorter, the better.
Sprint
A period of time in which the team will deliver a set of User Stories. This is usually 2 weeks, but can be adaptive as required.