User Story Flashcards
What is cone of uncertainty?
It’s when you’re forced to make all the predictions at the time when you have the least information.
Sprint
A short completed deliverable
Long pole in the tent
Items that the team predicts will take the most time.
User Role
User role is not a person. Bundle of experiences. Not stakeholders. Stakeholders are persons. Example: Customer / Premium Customer.
Context, Character and Criteria of User Roles
Context: Bundled experiences that the person will have based on where they are in your product.
Character: Role-Specific motivations and needs of the user.
Criteria: A user’s expected outcome(s) from using the product.
User Story
Short story from the users perspective about what they find valuable in the product.
User Story Format
As a [user role], I [want/need/can][goal] so that [reason]
Example: As a standard customer, i want to see a list of benefits of upgrading to a premium customer so i can see if it’s worth the cost.
Three Cs of User Stories
Card: Recorded on 3x5 index card.
Conversation: Having a group conversation.
Confirmation: Acceptance criteria. Written on back of the card. Acceptance criteria closely match the front of the card.
I.N.V.E.S.T of User Stories
Independent - Stories should be as independent as possible. When thinking of independence it is often easier to think of “order independent”. In other words, stories can be worked on in any order.
Negotiable - A story is not a contract. A story IS an invitation to a conversation. The story captures the essence of what is desired. The actual result needs to be the result of collaborative negotiation between the customer ( or customer proxy like the product owner), developer and tester (at a minimum. The goal is to meet customer needs, not develop something to the letter of the user story if doing so is insufficient. Ask “how do I know I’ve done that?”
Valuable - If a story does not have discernable value it should not be done. Period. Hopefully user stories are being prioritized in the backlog according to business value, so this should be obvious. The story has to have value to the “user” in the user story.
Estimable - A story has to be able to be estimated or sized so it can be properly prioritized. A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.
Small: Obviously stories are small chunks of work. Smaller the story it is easier to estimate time.
Testable - Every story needs to be testable in order to be “done”. Testable meaning acceptance criteria can be written immediately. Ask the magic question, “How do I know I’ve done that?”
Epic
Large grouping of work with common objective. Ex: Updating the database. Naturally grouped together that need to be split up.
Epics : F.E.E.D.B.A.C.K. method for splitting up Epics
F - Flow - This is how the story might step the application workflow
E - Effort - Based on developer’s level of effort
E - Entry - Based on how user enters the data
D - Data Operations - Based on common data operations CRUD
B - Business Rules - The rules that help you expand the goals of initial Epic.
A - Alternatives - Based on alternative criteria
C - Complexity - Broken down into stories with increasing complexity
K - Knowledge - Have to research the epic and break it down into stories. Story spikes aren’t stories but they lead to stories.
Agile Charter
Agreement but not a plan. One page or less. Three main sections. Vision, Mission, Success Criteria.
Vision - Why are we doing this project
Mission - What everyone will do to accomplish the mission
Success Criteria - Simple one sentence tests to make sure that the project accomplished its mission.
Relative Sizing
Method for predicting task effort by comparison or grouping tasks of similar difficulty
Benefits of Relative Estimating
Removes false comfort of “precision”
Clarifies estimates vs. commitments. Need estimates.
Planning Poker
Agile-influenced card game used to facilitate estimated and reduce group think. Uses story points and not hours.
