In a previous blog, I raised some objections to the acronym INVEST, a widely-used definition of what a good story should be. In this post, I introduce the alternative acronym that we use: VISIT. More importantly though, I provide a concrete and rigorous definition of a story.
The acronym VISIT stands for:
- Small (as small as possible)
- Independent (as independent as possible)
In fact, the overriding statement is that stories should be Incremental: Testable and Valuable are part of the test for whether a story is truly Incremental.
Here is what we mean by "Incremental": take a system which is complete and self-consistent with a certain amount of value; after playing a story, you should have a new system which is complete and self-consistent, which has more value. A story can be thought of as a state change, providing an Increment of capability. The words Increment and Story can be seen as synonymous.
Because a story results in a complete system, it therefore follows that the story is Testable using end-user functionality.
When asking whether the new system has "more value" we are explicitly talking about external value, i.e. deployed, usable value. This is in contrast to internal value, which might provide validation or learning, but is of no direct value to the end users.
So here is a clear, explicit definition: a story is an incremental system improvement that is complete (testable through end-user functionality) and adds external value.
What about Independent and Small?
It is desirable that stories are Independent (because there's more scope for prioritisation). It is not essential though. Increments are, by definition, going to build on each other, so that basic capability needs to be built before more advanced capability. One should certainly ask whether there is unnecessary dependency between stories and remove it.
It is also true that stories should be broken down into the smallest possible valid increments before they are played. The breakdown and refinement of stories occurs throughout the project, so at any point in time some stories may not yet be as small possible.
The danger of having small as a criterion is that stories are then broken down too far, so that they are no longer valid increments. This leads to all kinds of confusion and bad practices. What happens when stories cannot be broken down small enough to be played within sprints? This will be the subject of the next blog.
How does VISIT compare with INVEST?
Valuable and Testable remain unchanged. Independent and Small have been retained, but as second-class citizens. Negotiable and the Estimable have gone, and Incremental has been added. It can be argued that a key part of Estimable, that the story is concrete, is now captured more clearly by Incremental. Negotiable is more to do with the lifecycle of a story than whether it is a good story in itself.
As a final note, using the word Increment has caused some confusion with people aware of the Iterative vs Incremental debate. In the context that we are using it, an Incremental step change can equally be an addition of new capability or a refinement of existing capability.
In the next post, I will describe how focusing on the smallness of stories can reduce the benefits of Agile.