The foundation of every agile team’s delivery and execution is the user story. It’s the building block that defines practically anything a client might want to build. This series takes a look at how to get this important element right for an agile team.
A user story is a small chunk of work for an agile team to execute. Instead of trying to build an entire feature or a user journey slowly and serially (death by waterfall!), agile teams carve up the features and functionality of an app into small pieces of digestible work.
If your user story is legit, each story card includes a sentence redundantly called the “user story,” which follows the format:
As a [user]
I want [to do some function]
So that [business value is generated].
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:
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.
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.
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:
As a banking customer,
I want to deposit money via the ATM,
so that I can deposit funds into my checking account.
The function of the user story is the same as the business value being described. A better definition of a user story’s business value always approaches things from the user’s point of view—it steps outside of the mechanics of the app or product itself and thinks about the benefit being created for the user:
As a banking customer,
I want to deposit money via the ATM,
so that I gain time and convenience
by not going inside the bank and waiting in line.
User stories, when written correctly and with enough detail, are estimable by the team. This means that there’s enough detail for the team to understand what they’re building and why, and also enough to give the team direction on how they will design and deliver the story. If the team can’t estimate a story, it invariably comes down to too many questions and lack of information. Either a spike needs to be executed first, you need to talk to your Product Owner for clarity, or your story is just missing details. Stories that aren’t estimable don’t get picked up and thus contain no value.
Good stories are small. They’re not meant to hold a boatload of information, just enough to get a software engineer started. Details can be filled in as the team gets into a sprint. If carving large features into truly independent user stories—as we described above—is the first step towards breaking work into small digestible chunks, then making sure stories are small enough is the second step.
It’s a tricky balance. You want your stories to be small enough with enough details so that the team can estimate with confidence. But you also don’t want your stories to get so small that they become tasks that lose the forest for the trees—or in the case of our “so that” clause—your stories lose sight of the value being created for the the sake of documenting minutiae. There’s nothing more depressing to a Product Owner than seeing a product backlog full of technical tasks that never get anywhere near addressing user value.
Lastly, every user story should be testable. This sounds simple but is often something that’s overlooked. First, every agile team worth its chops includes “test complete” in their checklist of calling a story “done”—there might be varying levels of definitions as far as how much unit testing, integration testing, or test cases were written and performed so that the story passes the team’s standard of TDD, but there’s always testing to ensure code meets quality.
Secondly, asking the question, “How can we test this story?” is always a great question to ask when you’re putting a user story together. Stepping back and thinking about testability is a great way to approach your story’s requirements from another point of view and often surfaces hidden considerations or requirements that otherwise get overlooked. If a story’s not testable, it shouldn’t be teed up for the team to estimate, let alone included in a sprint.
That’s all for now! Making sure your stories are INVESTable is a great start. If you’re interested in more fine-tuning for good user stories, stay tuned for more posts in this series.
This article is part one in an ongoing series of three articles about good user stories.