A rookie mistake writing a user story
Writing a good user story is a delicate art. It should be clear, inspiring, leave enough room for creativity, and embody the product vision. It should be a self-contained piece of work without describing the solution. The user story is about WHAT, the HOW is up to the scrum team to figure out. Thinking in questions is much more creative than thinking in solutions but every once in a while I fall into the trap of thinking in solutions. Then I write a user story that is too descriptive. The result is that opportunities are missed, thinking becomes too narrow, and solutions become sloppy.
Get what you asked for, not what you want
There is this great clip from the movie The Smurfs where an executive explains to a new marketing manager why she fired the last marketing manager: “He gave me what I asked for, not what I want!” :)
What I want as a product owner is for the team to be creative, critical, analytical and when I write a user story that is too much a solution, I get that solution and that is not what I want.
Ok, let’s share this epic failure of a user story here to show you what I am talking about:
“As a user, I want to see the extra name that has been added to my legal debtor name in the list of my debtors, so I can more easily identify what debtor I want to explore.”
As can be read on the website of Atlassian, a user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer. This user story is an informal explanation of a software feature. It also more or less describes how it will provide value to the user. It even adheres to the basic user story format of “As a …., I want ….., so I can….” But this is where the good news about this user story ends.
I could have asked why, maybe multiple times to get to a deeper articulation of the value. But it was a simple feature. Just a quick fix. The solution was easy. A user doesn’t want to see the extra name. Users just want an easy and clear way to identify what debtor they are looking at. This user story is too much of a solution. I also wrote where the users supposedly wanted to see the extra name: in the list of their debtors. I also wrote what users wanted to see to differentiate between different debtors: the extra name which is the name of a specific field in a back-end system.
So naturally, I got what I asked for but not what I wanted.
What I wanted
What I wanted was focus on the user, creativity, and critical thinking. This user story gave me none of that. By writing a solution for the user in this user story, the team didn’t have to think about the user and their state of mind and needs. They only needed to build the solution. So there was no focus on the user. By defining what the user wanted specifically, there was no space for creativity in the team. The solution was already in the user story, so there was no need for creativity. And finally, because there was no need to focus on the user and no need for creativity, there was no critical thinking.
This resulted in a solution that missed a piece of the puzzle. It resulted in a partial solution of the user’s problem. Classic rookie mistake.
What I should have written to get what I needed
So, this all got me thinking how I should have written the user story to get what I needed: a total solution that creates value for the user. Starting from a solution that pops up is an easy trap. One of the ways to get out of that is to ask why. Why does the user want to see the extra name? Because the user wants to differentiate between different debtors that have the same name. Why does the user want to differentiate between debtors that have the same name? Because this reduces cognitive load trying to differentiate between debtors. Why does the user want to reduce cognitive load? Because this reduces the chances of errors. Why does the user want to reduce errors? Because errors are frustrating and cost time and thus money.
So maybe a user story like this would have gotten me the user focus, creativity and critical thinking I needed:
“As a user, I want an easy way to differentiate between debtors that have the same name, so I make less errors and this saves me time and money.”
The downside of creativity-inspiring user stories
Maybe this would have been better. But maybe there would have been a downside to this user story that is more creativity inspiring because it leaves more room and is not pushing for one solution. Not every user story needs to be an all-in in-depth exercise in creativity and creative problem solving. When the solution is obvious, exploring different solutions and doing extensive research might be overkill, right? Maybe it’s not up to the product owner. But maybe it is a balancing act between speed and creativity and that is reflected in the user stories. I was just surprised when I saw the solution when it was built. Because it only solved part of the problem, I went back to the user story and saw that I got exactly what I asked for. But not what I needed.
Thank you for taking the time to read this essay. I hope you enjoyed it. If you clap for this essay, I will know I connected with you. If you follow me here on Medium, you will see more essays pop up on your Medium homepage. You can also subscribe to an email service here on Medium which will drop new essays right into your inbox. You can also connect with me on LinkedIn to see new articles in your timeline or chat with me there.
