The Shapes of User Stories
I often wind up helping groups understand some aspects of agility and Scrum. One common topic that seems to confuse groups is user stories. I want to go over several shapes they tend to appear in and close with my desired one. Hopefully, you’ll see the shape yours take and the tradeoffs.
A User Story?
User stories are probably the most common way agile teams communicate about the product they desire to build. They came about as a response to long requirement documents full of mistakes or were outdated before the writing finished.
They are a move away from detailed written requirements to higher-bandwidth in-person communication about the desired request.
Shape 1: Story as Requirement
User stories typically have a format that goes something like: “As a __ I want __ so that __.” User stories as requirements show up right here in this template. User stories as requirements often appear as, “I want ____.”
This happens because the people thinking about the product are still working the way they used to, which is to collect requirements and deliver them to the software team. So the template provides an early warning system, as when people are thinking requirements, they stop thinking of anything else.
By the way, those two parts that are missing are the user or customer who wants the feature and why they need it. Those two things don’t matter when you are focused on requirements.
The next hiccup about the requirement shape is that success and failure are bound to the correctness in the requirements, and by extension, the person giving them. If they specify a broken, bad, insecure, or costly feature, that mistake was on them.
This shape can be beneficial if the person specifying requirements is right more often than wrong (Which they aren’t) and is easily understood (And they aren’t). Don’t be fooled though, anyone who has tried this before knows that communicating this stuff is monumentally hard. So much so that some smart people got together and said that we should move away from detailed requirements!
Shape 2: The Acceptance Criteria
Somewhere down the line, people decided that the story template was inadequate. And it is, purposefully. It forces people to talk and discuss. The response to this inadequacy was to add more stuff to it. This lead to the creation of Acceptance Criteria.
Acceptance Criteria are the, ahem, the minimum requirements for a story. Now, this is a little different than the first shape. When used well, the whole group uses acceptance criteria to remember what they decided in their conversation.
A little less great, but far more common, is the acceptance criteria are written in advance and given to the team as a way of saying that they need to build at least those things.
What tends to happen in this case is that people read the acceptance criteria as a list of requirements and forget the story exists. Teams put blinders on and build to each criterion—nothing more, nothing less.
In this world, we wind up with lots of features built, but nobody remembers who uses them or why. When we ask a team of smart people to work with blinders, we lose a lot of those smarts. We lose sight of our customers and the needs, and the chances of overall product success drop significantly.
Shape 3: Once Upon a Time
This shape is my favorite way stories go, and also really rare to see in practice. Teams may or may not use the template, but for now, let’s assume they do.
When a story comes up, the team discusses each aspect of the template. We talk about the customer and what problem they have that lead to this request. We talk about what other options there are as we talk about the want or need. Lastly, we discuss if those parts all triangulate to the purpose or why. Often, by the time we talk about the why, we realize there might be a lot more we want to know and many other options we could explore.
In the end, everyone negotiates down to something small that they can build. Since there are no requirements, we recognize the inherent guess that we’re making and build that allows for easier change. Each day some questions come up as we attempt to develop. Conversations are constant, and ideas are bountiful.
Stories are done when we believe we’ve got something that could meet our customer’s need, and it is built to the team’s internal standards.
Sometimes we realize that so much happens that we need to write some things down to remember. The team decides whether through acceptance criteria, chat history, comments on a site, or something in a wiki. When a debate comes up about what we thought we were doing, we pull it up and quickly recognize that most of the time, we only thought we decided something and move on as it isn’t vital.
Our backlog is full of new ideas and ways to refine earlier attempts. The best ideas are the ones that prove themselves out after everyone’s brain had a crack at solving it.