This is a continuation of my July 16th blog on User Stories.
User stories in the simplest form is documentation for Agile delivery. However, User stories are not necessarily requirements. There is a fine line between a user story and a requirement and difficult to often distinguish.
A user story is different than the “must have” requirement in that although it provides the instructions on who, what and why something is being built, a user story should be a transparent conversation between the product owner or user/Business Analyst and the delivery team.
It follows the “Card,Conversation,Confirmation” model brought forward by Kent Beck when Extreme Programming was intorduced into the IT world. User Stories should focus more on making sure the two groups understand each other on the delivery and less on say following a template or having a well written document. The conversation should lead to building the right solution (at least the right solution understood at that time) instead of just following instructions in a document like a recipe. When you create something new, recipes are meant for documenting what has been made, but not the acting the actual process of getting to that recipe.
As a final point, the relationship between the Product Owner, the team and Scrum Master must be built on trust and frequent communication in order to form and evolve excellent user stories. Otherwise, user stories will miss key information and lead to unnecessary rework.