There still seems to be confusion around what exactly a story is, and how you differentiate between good and bad stories. There are existing answers out there, but there is still too much vagueness. This is the first post in a series proposing a more definitive answer.
The de facto criteria for stories is the acronym INVEST. When an organisation that we are supporting tried to use INVEST though, we found ourselves resorting to phrases like: "it should only be used as a guide". This is an unsatisfactory situation.
So what are the problems with INVEST?
Independent. It is clearly a good thing if stories are independent. However, a good way of splitting a large story into smaller parts is to implement a simple end-to-end version, followed by a number of incremental enhancements. In this case there are clear systematic dependencies.
Negotiable. The intention is to make it clear that the detail written down is not a specification. This is not really related to whether the story is a good story. It is more about whether it has been expressed well.
Value. Absolutely, no question, a story should deliver value. But we need to be explicit about what kind of value. Ultimately, it should deliver value against the defined success criteria of the project. While some definitions make this clear, other definitions of INVEST allow for "internal value". In practice, it is very common for people to find all sorts of spurious value to justify a story. I have even heard arguments that design documents can be described as stories because they add value to the project.
Estimable. This is one of the two big problem areas. We spend a lot of time trying to undo the thinking that a certain degree of solution certainty is required before you can estimate. We would argue that anything is estimable, with varying degrees of estimation certainty. And ultimately, an estimate can simply be a statement of prepared investment. One argument I have heard is that "estimable" can be taken to mean "concrete", to avoid stories which are conceptual or nebulous. But nebulous is still estimable.
Small/Sized Appropriately. This is the other big problem area. It is true that stories need to be of a certain size to be played in sprints. However, the adoption of size as a primary attribute leads to behaviours which are counterproductive. Here's an example: the smallest end-to-end path through a system which is deployable and could be considered to have value could be three sprints-worth of work. It is not therefore a story that can be played, so we need to break it down – so what are we breaking it into? Smaller stories? But we have already said that it was as small as it could be while still meeting the other criteria. What tends to happen is that the other criteria are relaxed to achieve Small – "well, it doesn't deliver true value, but at least it can be reviewed" – but now you've introduced "internal value" as a valid criterion.
In the next post, I will propose an alternative to INVEST – VISIT.