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.

Definition of Ready

Dear Scrum Master, Don't let anything that's not READY into your Sprint.

Imagine, you are going to cook a meal for your spouse for your anniversary evening. Before starting to cook, you actually check, whether all the ingredients are available, you check if those are in the sufficient quantities, you buy out the missing things and then you start cooking, Right? The same is true for user stories.
User stories after their birth, have very tiny details. It is difficult for the team to commit to such stories. Team needs discussions, analysis, arguments and negotiations to groom the stories, so that the stories become matured and then team can commit to the stories.
But how does a team know, if the story is really ready to be taken into the sprint?
As user-story becomes clear and team doesn’t have any unanswered question and dependency remaining, the story is considered "READY". The list of items which help us to identify the "READY"ness is called as Definition of Ready (DOR).

Every user story must satisfy the INVEST criteria, before team commits to it. Every dependency

from the story needs to be removed, before team commits to it. All the necessary softwares and hardwares must be ready, before team commits to any story. These and many more items comprise into a list i.e. DOR.
Before committing to any story, the team can check if the story meets all the DOR criterion. If not they can reject the story, so that the stakeholders can put the missing details into it.
Agile promotes "Courage" as its core value. Courage to say "No" is important while committing for the stories. DOR gives us the sensible reasons to say "No".