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
- September 14, 2022
- Build in Small Batches
I want to conclude this collection of seven blog posts on strategies for story splitting with one of the most important aspects that a story should include, which is the ability to be tested.
Just like testable code, testable stories are essential. When we make stories testable, we find that many of their other qualities also improve.
We start by asking what is the main value of the story and how will we know when we’ve achieved it. This helps keep us focused on the core of the features that we’re building and what it means to the user. This often helps clarify exactly what the feature is about, so we can write the story in a way that clearly expresses who it’s for, why they want it, and exactly what it is that the story is to achieve. This also helps us clearly define our acceptance criteria.
In fact, testability really reflects our story’s ability to verify its acceptance criteria. In other words, what we need to test in our story is if we achieve the desired intention. Another way to ask this question is, has our user achieved their goal or their “why” clause of the story? Keeping stories testable also helps keep us focused on achieving the acceptance criteria of a story.
Ultimately, the only thing that a computer can really do is change the state of some memory. If we are automating a task, then often what we need to do is identify the preconditions when we start and the post-conditions when we end. The difference in the state of the system from when we start to when we end, which is caused by the triggering event, is one way to recognize or define a story.
We can formalize this into a structure that we call the “given-when-then” clause. Given some precondition, when a trigger occurs, then some post-condition should be created that we can then use to compare to an expected post-condition.
Thinking of stories in this way allows us to easily test them and also to automate the process using an acceptance test-driven framework. These frameworks may take a bit of effort to get set up but once they are set up they can give clear visual feedback that all the stories are passing their acceptance criteria and if any fail they immediately generate an alert.
Acceptance tests are great ways to track the progress of story development and then to keep track that all stories are working as expected while new features are added to the system. And this gives us a true measure of our progress as we’re building a system.
This concludes my seven blog posts on “Seven Strategies for Splitting Stories.”
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set here. The next seven blog posts are expanded versions from “Seven Strategies for Splitting Stories”. You can find the original post here.
Previous Post: « Keep Intentions Singular
Next Post: Integrate Continuously »