How to write User Story ?

Over the years I have worked with quite a few Product Owners and also I have played that role myself but often I have seen people having very minimal knowledge about writing good user story and that does impact development. So this post is all about it how to write good user story!

Before I get into it I prefer to put an example of how an user story should be written:

If you notice this example meets the following high level definition of what a Product Owner should write:

• Provides a simple medium for
• Gathering basic information about stories
• Recording high-level requirements
• Developing work estimates
• Defining acceptance tests [Normally been written in the back of 4"X6" card, however if you are using any online tool most of them provide acceptance criteria block.

• Acts as agreements between customers and team members to discuss detail requirements during an iteration

However, here I have put together the detail definition we should capture in user story and here the participants are Team and Product Owner who needs to write this together:

• Story identifier and name
• Story description: A sentence or two that describes the feature in customer terms
• Story type (C = customer domain, T = technology domain) [E.g. customer domain would be something which comes from customer thus this is nothing but features whereas something would be called as technology domain which comes from the team say refactor certain area of the code or support they need to get something done etc.]
• Estimated work effort: The estimated work effort needed to deliver the story, including time for requirements gathering, design, coding, testing and documentation.
• Estimated Value Points
• Requirements uncertainty (erratic, fluctuating, routine, stable): An "exploration factor" for a specific story
• Story dependencies: Dependencies that could influence implementation sequencing
• Acceptance tests: Criteria the customer team will use to accept or reject the story.