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
- August 24, 2016
- Build in Small Batches
There are many techniques for splitting stories depending upon the situation you’re in. The goal is to break down work into the smallest increments that still provides some value, but the value can simply be a step in the right direction—as long as it produces visible results.
Most big stories are compound stories, meaning they’re made up of other smaller stories. If this is the case, simply break down the compound story into its component stories. This may have to happen repeatedly in order to break down a story to its smallest valuable component.
If the story includes unknowns, break out the known from the unknowns and begin iterating to the unknowns until they’re better understood and the domain of the unknown shrinks to nothing. In situations like these, it’s good to spike an unknown by researching specific questions in time boxes. At the end of the time box, evaluate your progress on answering your question. In this way you can eliminate the unknowns.
If a story represents a work flow or sequence of steps needed to accomplish a task, you can either thin-slice the sequence so you’re doing a very simple version of each step then devise additional stories for implementing each step in more detail. Alternately, you can create stories for each step in detail and string them together, if that makes more sense.
If the story acts on different data in similar ways, then you can make it work for a simple case and then have subsequent stories that work on the different data sets.
In some stories, it makes sense to write the happy path first and then write additional stories to handle exceptions, while in other stories it makes sense to peel off exceptions as individual stories that drive you to the happy path. Whether you choose one approach or the other depends upon the preconditions required and the complexity of the exception handling.
Regardless of the techniques you employ to split stories, the goal is that each story be a step toward overall completion and that it satisfies some acceptance criteria. It’s important to always have a clear criterion for when your story is done so you know when to move on to the next story.
And that’s it in a nutshell.
Previous Post: « Splitting Stories
Next Post: Programming by Intention »