The basic framework for a good user story has 3 parts: identifying which user/role (or other stakeholder) benefits, what that person wants (the goal), and the payoff (why it’s important).  You’ll often see this framework expressed as the following template: “As a ________, I want ______, so that __________”.   To paraphrase Mary Poppendieck’s quintessential requirements example,

“As the VP of Distribution, I need us to redesign the REAR windshields of our cars to withstand wind-speeds of up to 130 MPH (as our FRONT windshields already do), so that we don’t have any more accidents when our cars are loaded onto transports facing backwards and then hauled at 70 MPH into a hailstorm with headwind gusts of 50 MPH.“

Since the second blank represents a goal, a lot of user-story writers find the SMART mnemonic helpful.  It’s one that’s taught in traditional goal-setting seminars, but as you can see, there’s no consensus on exactly what the mnemonic stands for:

Specific / Significant / Stretching
Measurable / Meaningful
Attainable / Achievable
Realistic / Relevant / Reasonable
Time-bound / Testable / Trackable

So, a better mnemonic that’s especially pertinent to user-stories is INVEST (think “Return-on-INVESTment”):

Independent
Negotiable
Valuable
Estimatable *
Small
Testable

* Or “estimable,” if you prefer the proper English spelling.

The trick to writing a good user story is to define it well enough that the expected return on investment (ROI) pops out.  The “return” factor is the payoff part of the story (“so that..”), and the investment factor is the estimate, as determined by the Scrum Team.  The lower the estimate and the bigger the payoff, the better the ROI.   The body of the story (“I want ____”) describes the actual requirement, and that’s what the Scrum Team will use as a basis for their estimate (supported by the payoff statement, of course).

A well-written story will instantly remind the Product Owner (PO) and the team of all of these factors every time they read it, so that the stories can easily be discussed in the proper light, making Sprint planning sessions more productive and meaningful.

Independent — Stories should not be dependent on one another (other than via an explicit story-order as defined by an epic). This is what allows for the arbitrary reordering of the stories by the PO and makes the whole Sprint Planning process possible.

Negotiable — This, among other things, is a reminder that a good story defines WHAT needs to happen, but leaves it up to the Scrum Team to determine HOW.  If a story writer tries to be too proscriptive here, he/she may get back an unexpectedly high estimate.  But, if he were to allow a little wiggle room, not only might he see a lower estimate — making the ROI shoot up — but he might also get a better solution than he originally envisioned.

Valuable — This, again, is a reminder that the payoff part of a story (“so that ____”) is oh so important. In the example above, if we were to leave out the part about cars being transported backwards, we’d leave a lot of people scratching their heads and wondering why a rear windshield could possibly need to withstand 130 MPH wind forces.

Note: I’ve seen the INVEST mnemonic defined elsewhere with the V being “delivering value to the end user,” but the end-user is not the only stakeholder that derives value from a system.  The Product Owner represents many constituent stakeholders, from the people who control the purse-strings, to the lawyers and regulators, to the system administrators, and so on.  A story might exist to deliver value to any one of them.

Estimable and Small — These are key aspects that support the Scrum Team’s side of the negotiations, affording them a certain measure of confidence in the estimates they produce.  If a story is too big, the team won’t be able to get a good handle on everything that needs to be done and any estimate offered up will be wildly off.  Also, it’s hard, if not impossible, to plan sprints around stories that are too big.

Testable — If the testability of a story isn’t clear, then either it’ll need to be reworded, or else it’ll need to be accompanied by explicit user acceptance criteria stated separately, because without a clear idea of how to prove the doneness of a story, it’s almost guaranteed that the PO and the Scrum Team will not be seeing the story in the same light.