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
- November 11, 2020
- Build in Small Batches
Stories should be as small as possible while still providing some value to the user. Usually, we strive to create the smallest increment of value possible but this is sometimes not as straightforward as it may seem.
Sometimes we write stories with the intention to build upon them later or combine pieces of common stories so that when the first story is done other subsequent similar stories are much easier to complete.
Every story should provide some measurable value or at least some measurable result. Having a repeatable, measurable result for each story helps us define acceptance criteria for our stories that tell us when we are done building them so we can move on.
On enterprise projects involving several teams, we may want to build out some infrastructure or libraries in service to other teams. Scrum says that it is generally better to do the most important stuff first. I resisted such a simplistic approach but it usually works out that focusing on building the most important stuff first ends up building the best system possible with the resources I have.
When we build the most important stuff first, we end up ignoring a lot of the unimportant stuff so we only build the stuff that is most needed. If you can see a way to make a big story, into smaller stories then generally, it’s a good idea to do it. Alternatively, you can start with a simple story and add additional stories to enhance the original story. This works well in iterative development.
When I work on projects that use automated acceptance tests, I find that oftentimes stories are naturally centered around acceptance criteria and the value to the user. Even if these stories are larger, they can often be decomposed into smaller component stories.
A story should be focused and provide a single value to a single type of user for a single reason. Enhancement stories can be added to improve the feature.
So keep it small and that’s all I have to say about that.
Previous Post: « Polymorphism
Next Post: User Stories Support Object-Oriented Development »