Good User Stories
Writing good user stories is a real art. I have no doubt that I still have a lot to learn in this regard, but from my limited experience I’ve definitely seen some user stories which are very good and some which are very bad.
One of the discussions which often comes up is whether or not something qualifies to be a user story. More specifically, we might want to introduce a more technical story – which means we would have to choose between creating a new user story or lumping it with one of the existing stories. While there is no right or wrong answer, I like the idea of viewing user stories as a planning tool – we shouldn’t be afraid of creating a story to aid in our planning.
While reading the RSpec book I came across a very good test to determine if something qualifies as a user story. According to Bob Koss a user story must have the following characteristics:
Have business value. To me, this is the key when introducing more technical stories. A feature doesn’t necessarily have to directly be used by a user in order to qualify as a story. It only needs to add business value.
Be testable. We need a set outcome, and therefore we need to be able to test that outcome. Otherwise we don’t know when the story is complete.
Be small enough to implement in one iteration. This speaks to the need to balance implementation concerns with requirements. We want to keep the stories small, while still keeping a single piece of functionality as coherent as possible. As I said, it’s a real art.
While creating good user stories is easier in theory than in practice, I really like the idea of evaluating stories against these characteristics. Happy coding.