User Stories

A user story is used to define product or system functionality and the associated benefit of the functionality.  In an Agile environment, projects are commonly comprised of a large number of user stories representing various levels of system/product user. This ever growing and prioritized list of user stories is called as product backlog. The user story describes the type of system/product user, what functionality they want, and why they want it. The format of a user story should be:

As a <type of user>, I want to <feature/function> so that <reason/value>

INVEST in user stories and perform SMART tasks

What is a good user story?

In scrum, we get married to user story. Have you ever thought of which story is good to get married and which is not? What are characteristics of a good user story? The acronym "INVEST" can guide you to identify the good stories:

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable

Independent

Stories are easiest to work with if they are independent. Its better for them to neither overlap with nor depend on other stories and we should be able to schedule and implement them in any order.
We can not always achieve this. Once in a blue moon, we may say things like "3 points for the first screen, then 1 point for other screens."

Negotiable

A good story is negotiable. It is not an explicit contract for features. The details will be co-created by the customer and development team during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.