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.

Valuable

A story needs to be valuable. It needs to be valuable to the customer. Customer is important.
This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no presentation layer.
The format of the user story ("As a ......, I want ..... so that ......"), include "so that ......" clause which indicates value of the story.

Estimable

A good story can be estimated. We don't need an exact estimate (because estimates can never be exact), but just enough to help the product owner rank and schedule the story's implementation. Being estimable is partly a function of being negotiated. It is hard to estimate a story which we don't understand. It is also a function of size. Bigger stories are harder to estimate. It is also a function of the team. What's easy to estimate will vary depending on the team's experience. (Sometimes a team may have to split a story into a (time-boxed) "spike" that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.) Spike does not have estimates as it is assumed to be time-boxed.

Small

Good stories tend to be small. Excellent stories typically represent at most a few person-hours or days worth of work. Smaller stories tend to get more accurate estimates. Bigger stories have more uncertainty.

Testable

A good story is testable. Writing a story card carries an implicit promise: "I understand what I want well enough that I could write a test for it.". Writing the tests early helps us know whether this goal is met.
If a team and the customer doesn't know how to test the story, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing.
A team can treat non-functional requirements (such as performance and usability) as things that need to be tested.

What is a good task?

Once you get married to a user story, you create tasks with it to make your marriage successful.

How can you check if your marriage will be successful or not? What are features of good tasks?

S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-boxed

Specific

A task needs to be specific enough that everyone can understand what's involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story. E.g. "coding", "system testing", "database column addition", "script review".

Measurable

The key measure is, "can we mark it as done?" The team needs to agree on what that means, but it should include "does what it is intended to," "tests are included," and "the code has been refactored."

Achievable

The task owner should expect to be able to achieve a task. Anybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.

Relevant

Every task should be relevant, contributing to the story at hand and pushing the story towards acceptance. Tasks are added under the story for the benefit of developers, but every tasks needs to be able to be justified.

Time-Boxed

A task should be time-boxed - limited to a specific duration. This doesn't need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help.

What to do with these acronyms?

As you discuss stories, write cards, and split stories, the INVEST acronym can help remind you of characteristics of good stories. When creating a task plan, applying the SMART acronym can improve your tasks. This is helpful for scrum master to see if the team is on the right track or not.

Origins of this concept

This post is highly influenced by below material.
In 2003, the INVEST checklist for quickly evaluating user stories originates in an article by Bill Wake, which also re purposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories. You can read more on this here.