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.
What would discussion of story splitting be complete without covering Bill Wake’s INVEST acronym? INVEST stands for:
The ‘I’ stands for independent. Independent stories should be stand-alone as much as possible. If we must have dependencies between stories, then a story should depend on a previous story rather than a future story.
‘N’ stands for negotiable because it’s really about the conversation around the story rather than the story statement itself.
‘V’ stands for valuable (or sometimes referred to as a vertical slice) because we want a story to provide ultimate value to a customer and be an end-to-end solution that goes vertically across slices to produce some unit of value. This really speaks to one of the most essential differences between building to stories rather than building to architectural layers.
In the past, I’ve built software in layers meaning that I would implement all the platform APIs first and then build my services on top of them, and finally put a user interface on top of that so that we could run the system. This is a horrible way to build software because you don’t really see everything running until late in the development cycle and we were constantly running into issues around integrating our code and making it all work nicely together. Instead of building horizontally, stories encourage us to build vertical slices of value, and this does a couple of things for us. First, it gets valuable features in the hands of our customers sooner but also it has us focus on implementing the most valuable things first.
‘E’ stands for estimable, which means that it’s easy to estimate. We get the ability to accurately estimate stories by making them as smallest as possible with clearly defined elements. Estimations are always more accurate when they’re on short horizons versus on longer horizons. For this reason, it makes sense to make stories as small as possible so that they’re more straightforward to estimate.
‘S’ stands for small. All stories should fit within the length of an iteration but ideally, story should be much smaller. Small stories are easier to schedule, and they also get verified sooner than large stories. In Agile, smaller is better, especially with stories.
And finally, ‘T’ stands for testable, which means that we can clearly define acceptance criteria for the story, and we use this to drive the creation of the story.
Bill Wake’s INVEST acronym is a handy way to remember six key aspects of well-written stories.
For me, the most important and the most difficult to achieve aspect of a good story is the first one, Independence. Often, I find that one story that I write depends on the existence of another story. This can be good if it’s allowing me to start with a simple story and then add from there but when multiple stories have interdependencies, it can be difficult to figure out what to do first.
As I mentioned, I used to spend a lot of time trying to figure out how to build architectural layers that would support the features I wanted to build but I prefer not to do this anymore and find that often if I just focus on building the most important features first, that I come up with a reasonably good order of construction and the technical practices that I use to build decoupled systems also helps me minimize dependencies. I find this approach works well for me most of the time.
Previous Post: « Split Stories on Acceptance Criteria
Next Post: Keep Intentions Singular »