Last few weeks I had a few experiences around Product Backlog Items and user stories that made me write this article.
Let’s start with a simple observation: many teams I have worked with and people I have met still have the notion that every Product Backlog Item should be in the form of a user story. Why? It is called Product Backlog Item for a reason, else the inventors of Scrum would have called it Product Backlog Story wouldn’t they?
User stories describe end user requirements and are quite powerful in doing so. But for technical requirements or non-functional requirements like performance, security, etc they are not well suited. Of course you can «force» them into user stories but why do you want to do that when there are other means to capture these requirements far more efficient and clearer? Natural language is not always the most well suited way of defining things.
The same goes for complex user interactions like workflows and scenarios. And also user interface requirements are better visualized as described in human language. Using math for actuarial models makes far much more sense as describing it.
What I am trying to say is just use the format that is most suited for the task when creating a Product Backlog Item. That is what agile is being about.
The reason I have not used the word writing in the text above about user stories has to do with my second observation: Many people using Scrum seem to be the opinion that you just write a user story.
Even when valuable principles are considered during the writing, like the “As a … I want … so that …” notion, that reminds us that we need to consider all the users of our product, that we need to consider what they want to accomplish, and that we need to turn that into a feature that they want.
Or the “INVEST” notion from Bill Wake, that reminds us that stories should ideally be Independent, Negotiable, Valuable, Estimatable, Small, and Testable.
These are all good things for a requirements creator to think about … and they are all valuable to communicate to the developers, to help their understanding of the requirement. But a real user story consits out of the three C’s: Card, Conversation and Confirmation. This formula from Ron Jeffries captures the three essential components of a user story:
– a «card» (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction:
– a «conversation» taking place at different time and places during a project between the various people concerned by a given feature of a product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
– the «confirmation», finally, the more formal the better, that the objectives the conversation revolved around have been reached.
You can write a user story in any form on a card and then create clarity by conversation between people that need to talk about it. During these conversations you can create additional documentation and add details to the card. Then you work on confirming the understanding.
That is what Product Backlog creation and refinement is all about. Not writing user stories or converting already clear requirements into user stories.
