2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- May 4, 2016
- Bits and Pieces
A story is a single sentence description of a feature.
Stories tell three things about a feature:
• What it is
• Why it’s there
• Who it’s for.
Stories do not tell how to implement a feature or even what it looks like. Stories are very high level.
Stories are placeholders meant to remind the Product Owner and developers to discuss a particular feature. It’s that discussion that replaces requirements and turn software development from blindly fulfilling a specification into a discovery process where the Product Owner and the development team work together to find the best solutions to problems.
For example, a story for an online auction system might read as follows:
As a registered user, I want to bid on a started auction so that I may become the highest bidder.
Stories typically have this format:
As a _____ I want to _____ so that I can _____.
The first part of the story says who the story is for. The story is written in the first person: “As a registered user, I…” I have now included an initial constraint: “as a registered user,” which would have been defined in the previous story.
The next part of the story says what the story is about. “I want to _____” This is expressed as a desire from the user, again in the first person. It’s important here to focus on the goal of what we’re trying to achieve while giving us as little information as possible about how to achieve it. The goal is to state what the subject of the story wants.
The last element of the story states why the feature is wanted “…so that I can _____.” The so-that clause really speaks to why the feature is wanted and what the subject will get out of it.
These three pieces of information are key: who it’s for, what they want, and why they want it.
It’s easy to get lost in implementation details or the look and feel of a feature, and sometimes we lose sight of the bigger picture: Why we’re building the feature in the first place.
Stories keep us focused on what the feature is all about, who it’s for, and why they want it. It helps us build a better product for our customers.
Previous Post: « Scrum Master Toolbox Podcast
Next Post: Dev.Cast »