2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – 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
- February 20, 2014
- Build in Small Batches
The shorter the story the better. Short stories are easier to estimate, understand, and implement. Short stories help create cohesive, uncoupled code. Short stories are easier to test. But how do we turn big stories into shorter ones? Here are seven strategies for splitting stories.
1. Break down compound stories into components
If a story is composed of sub-stories, break them out into multiple stories. This will help disaggregate components and make the system more modular. It also yields smaller stories that are easier to work with.
2. Break down complex stories into knowns and unknowns
Stories are typically complex because they contain unknowns. We may not know exactly what the customer wants or exactly how to implement it. Separating what is known from what is not known is the first step to splitting stories with unknowns.
3. Spike on unknowns until they’re understood
Once something is identified as unknown, encapsulate it! Hide it behind an abstraction with a well-defined interface. Then you have the freedom to learn more without it being in your critical path. It’s generally better to attack high-risk unknowns up front and defer low-risk unknowns until later.
4. Split on acceptance criteria
As we break stories down into tasks we still want to have some kind of visible evidence when a task is complete. Splitting stories on acceptance criteria can help focus development while still providing some customer value within an iteration. It also helps clearly define when the story is done.
5. Minimize dependencies
We would rather stories not depend on other stories, but sometimes that can be difficult to avoid. Try to remove dependencies by creating well-defined interfaces between dependent components. If you must have dependencies, make future stories depend on previous stories and not the other way around.
6. Keep intentions singular
A story should be about fulfilling a single intention or a verifiable aspect of that single intention. Often, we think about a story as providing complete functionality to the user and we make them too big. Smaller stories are easier to work with. They don’t have to be a full blown feature, just contain enough functionality for the user to derive value from it. Subsequent stories can enhance a feature to provide additional functionality.
7. Keep stories testable
Each story should have a series of acceptance tests defined as the criteria for acceptance. If stories are untestable or difficult to test then we won’t easily be able to verify them. Make each story have some demonstrable effect on the system so it’s easy to verify. Automate acceptance criteria whenever possible.
Story writing is a skill that’s honed over time. When stories are concise and disaggregated, systems are more focused and easier to build on. Keeping stories small, focused, and easy to verify helps to make systems clear and maintainable.
Previous Post: « Seven Strategies for Writing Better Stories
Next Post: Seven Strategies for Increasing Code Quality »