User Stories Expanded

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s