Neuron Technology

What is a User Story?

A story describes desired functionality from the customer(user) perspective.
A good user story describes the desired functionality, who wants it, and how and why
the functionality will be used.
The basic components of a User Story are sometimes dubbed as the three C's:
 1.Card - the written description of the story, serves as and identification, reminder, and also helps in planning.
 2.Conversation - this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
 3.Confirmation - the acceptance test criteria that the user will utilize to confirm that the story is completed.

A user story is not technical.

A well-written user story follows the INVEST model

Independent
Negotiable
Valuable
Estimable
Small
Testable
Let's see what each one means:
 ■Independent - One user story should be independent of another (as much as possible).
                        Dependencies between stories make planning, prioritization, and estimation much
                        more difficult. Often enough, dependencies can be reduced by either combining stories
                        into one or by splitting the  stories differently.
 ■Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the
                 story which do not include details. The details are worked out during the
                "Conversation" phase. A "Card" with too   much detail on it actually limits conversation 
                 with the customer.
 ■Valuable - Each story has to be of value to the customer (either the user or the purchaser). One
                  very good way of  making stories valuable is to get the customer to write them. Once a 
                  customer realizes that a user story  is not a contract and is negotiable, they will be
                  much more comfortable writing stories.
 ■Estimable - The developers need to be able to estimate (at a ballpark even) a user story to allow
                   prioritization   and planning of the story. Problems that can keep developers from
                   estimating a story are: lack of domain   knowledge (in which case there is a need for    
                   more Negotiation/Conversation); or if the story is too big  (in which case the story 
                   needs to be broken down into smaller stories).
 ■Small - A good story should be small in effort, typically representing no more, than 2-3 person 
                 weeks of effort. A story which is more than that in effort can have more errors
                 associated with scoping and estimation.
 ■Testable - A story needs to be testable for the "Confirmation" to take place.
            Remember, we do not develop what we cannot test. If you can't test it then you will never   
             know when you are done. An example of non-testable story: "software should be easy to  
             use".

Summary

Well-written User Stories are cornerstones for Agile Development.
They should be independent of each other; the details should be negotiated between the users and the developers;
the stories should be of value to the users; they should be clear enough for developers to be able to estimate them;
they should be small; and they should be testable through the use of pre-defined test