No story card is complete without this sentence. The user story tells the team what they’re going to work on, who will use the feature they’re building, and what business value they’re creating. So let’s take a look at each part of the user story.

“ As a user ” Who is the user? Do they fit into one of a few defined personas in the app? What do you know about what the user might be trying to accomplish in the app (their role, their permissions, their goals) based on who you know the user is? Are they customers, operators, developers, product owners, or something else? Usually you can do better than using the word “user” in your story.

“ I want to do some function ” What does the user want to do? What, functionally speaking, is the user trying to accomplish in your app? Or, more practically to an engineer, what does my code need to do?

“So that business value is generated” This portion of the user story captures the value that is being delivered to the product or customer through the story. In other words, there is a distinct piece of value for the business or the customer that is created when this story is complete and deployed to production.

Let’s talk about the basics you should know when it comes to a good user story. The simplest place to start is with Bill Wake’s INVEST acronym:

Independent

Good agile stories are discrete and independent, where a feature or user journey is divided in such a way that each story card can be executed independently. Stories need not be tied to APIs that don’t exist yet (because you can build stubs). Stories that build on multiple steps in a process don’t need to be coded sequentially (because you can always smartly design for assumptions in your story planning process). Creating truly independent stories is a hard skill that takes time to get the hang of, but done right, it opens up the team for fast execution.

Negotiable

Until they’re added into a sprint for the team to work on, stories are never written in stone. Every agilist knows that requirements change all the time. By virtue of being small and discrete, user stories allow product owners to negotiate scope and function on the fly—where requirements are allowed to change and be rewritten. But where you want to limit changes and draw a line in the sand is once stories are picked up by the team. Once the team has started code for a story, change becomes expensive and something you should avoid.

What if you come across a change for a story that’s already in play? This, too, is when you can negotiate and decide if it’s worth pulling the story card back for more analysis and resetting context, or if the story can be left as-is and instead create a separate card to address the change later.

Valuable

A good user story delivers value to the end user. Period. This sounds like a simple concept, but, too often, I see user stories where the business value hasn’t been articulated. Remember the end of our user story sentence, “so that business value is generated”? To use the classic example of building an ATM, I frequently see user stories like this: