I teach quite a few teams about User Stories. Most struggle with the concept, at least initially. One of the key challenges for many is the notion that stories are iterative. That you visit and refine them often, instead of the “once and done” view that we have for traditional software requirements.
Part of that revisiting is reinforcing the collaborative nature of the stories. The nature that says they are “intentionally incomplete” in order to encourage conversations around the story. Remember the 3’C’s from Ron Jeffries: Card-Confirmation-Conversation, with conversation being the most important ‘C’?
I thought it might be helpful to go through a life-cycle example of how stories morph and change as they approach an execution-ready state. So here goes a somewhat contrived example—
The user story has nearly become the ubiquitous requirements artifact in agile contexts. So much has been written about the user stories, their format, how to write them, the associated acceptance tests, and more.
As for acceptance tests, we’ve moved beyond writing them to articulating them as “executable tests” in tools such as Cucumber and Robot Framework.
All of this evolution has been great, as is the focus on the collaborative aspects of the user story.
But I’m starting to see something troubling in my coaching travels. I think we might be focusing too much on the user story as an agile requirement artifact. Instead, we should be taking a step back and considering the user story as a much simpler communication device.
That is simply as STORY, and much less as a written story, but more so as a story that is told…face-to-face.
