Last year, 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 I think it’s time to start expanding on the second set. But not all at once. Here is the first set of seven blog posts based on the section Seven Strategies for Writing Better Stories.
Agile says to get rid of long-winded requirements. Get rid of use cases. Get rid of specifications. What is Agile recommend we replace these documents with?
The answer isn’t just user stories because a story is just a single sentence that describes WHAT the feature is, WHY it is wanted, and WHO it’s for. That’s not enough information to build a feature with. But stories were never intended to be enough information to build a feature.
A story is just a placeholder for a conversation that happens between the Product Owner and the development team, and it’s out of this conversation that the team gets enough information in order to build the feature.
This conversation might start during sprint planning but continues throughout the development of the feature. This is why it’s important to have a Product Owner available to answer questions as the feature is being built because, rather than explicitly specifying all the details of a feature before we build it, we discover the details of the feature as we’re building it.
This turns out to be a highly efficient way of creating software. The time and effort required to write down requirements in the form of a specification document and then to read and interpret those documents accounts for a great deal of waste in the software development process. It’s been estimated that poorly defined requirements and the bugs that result from them cost half of our development budget (see https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf).
It turns out that we only have to write down requirements so that they are captured if we have a long development cycle. If it takes three months, six months, or even a year before the feature is actually implemented then we have to write down requirements and I think there is an enormous amount of overhead and waste that results.
But when we build to a feature and our development cycle is measured in weeks or more preferably in days or even hours then we won’t have to write much down, and this vastly improves the efficiency of our software development process.
Stories are valuable because they help us focus on the most important aspects of what we’re building, which is WHO it’s for, WHY it’s wanted, and WHAT it is. Notice that there is no room in a story for implementation details. The business of how to implement a feature doesn’t show up anywhere in the story and this is by design. We don’t want to leak implementation details into our stories because we find that it causes implementation details to leak into our code as well, and this makes code unencapsulated and difficult to change in the future.
By keeping stories focused on the WHAT, the WHY, and the WHO, we can keep the conversation at the right level of abstraction to define what to build and then leave it to the developers to figure out how to build it.
{2 Comments }
Previous Post: « Green Tests and Red Tests
Next Post: Focus Stories on the What »
Thanks for your post. The PDF link is not working for me.
Fixed. Thank you for letting me know.