Saturday Reading
Introduction to User Stories
- What problem do stories address?
— Software requirements is a communication problem
Advantages of the “As a user, I want” user story template.
As a <type of user>, I want <some goal> so that <some reason>.
- “As a such-and-such, I want …” you can see how the person’s mind goes instantly to imagining he or she is a such-and-such
- Having a structure to the stories actually helps the product owner prioritize
User Story
- written from the point of view of a person using your website or application
- written in the language that your customers would use.
As an <actor phrase > I want <action phrase> so that <outcome phrase/achievement>
- The actor makes sure you’re thinking about who will use this feature
- The action describes what will happen, but not *how* it will happen
- The achievement describes the ultimate purpose of the feature.
User stories: a beginner’s guide to acceptance criteria
Ron Jeffries wrote about the Three C’s of the user story:
Card — stories are traditionally written on notecards, and these cards can be annotated with extra details
Conversation — details behind the story come out through conversations with the Product Owner
Confirmation — acceptance tests confirm the story is finished and working as intended.
- Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
User Stories — Capturing the User’s Perspective Quickly and Simply
- Designing a product is designing a relationship.
User Stories vs. Use Cases
- User stories are about needs
- Use cases are about the behavior you’ll build into the software to meet those needs.
- User stories are easy for users to read
- User cases describe a complete interaction between the software and users (and possibly other systems).
What Characteristics Make Good Agile Acceptance Criteria?
As an <actor phrase > I want <action phrase> so that <outcome phrase>
- User Story, must be accompanied by “good” Acceptance Criteria to provide a way to clearly demonstrate
- Pre-established standards or requirements a product or project must meet.
Includes
— Functional Criteria
— Non-functional Criteria (design)
— Performance Criteria
- Acceptance Criteria should state intent, but not a solution
How reducing your batch size is proven to radically reduce your costs
- When we work with small batch sizes, each batch makes it through the full lifecycle quicker than a larger batch does
- You’ll deliver faster and reach project completion earlier
- Faster feedback — the sooner you pass on your work, the sooner you’ll know if there’s an error
- Better feedback — you’ll know earlier on if you’re building the right product, because you’ll get it in front of your customer sooner
- Greater visibility — bottlenecks and inefficiencies are clearly seen
- Reduced complexity — you’ll reduce the amount of complexity that has to be dealt with at any one time by the team
- Smaller batches = greater output
- Reduce the timeframe for delivering results
- Don’t define all your requirements and success criteria in one go
- Prioritise your product’s features and begin with the smallest amount of work that will still deliver value to your customer
- Test and release as soon as that work is complete — adopt continuous integration and ensure deployment and testing efforts are ongoing during your project
