The Art of Writing User Stories
A program is not built; it is grown. -Chris Pine
This quote has resonated with me since I began my learn-to-program journey. I liked the concept immediately when I first read it, even if I didn’t fully understand what it meant to “grow” a program.
Certainly there are programs that are built. Probably most of them are. I am definitely guilty of “building” a few sites. I plan it all out to pixel perfection, write some code to execute my vision, high five myself (clap, I guess?), pour myself a drink, send out the link… and never touch it again (the code, that is.) There might be more features I wish it had, and I might have intentions to work on them or finish someday, but eventually it withers. I’m not exactly known for my green thumb.
A couple weeks into the Web Development Immersive course at General Assembly we learned about Agile methodologies, test driven development, and behavior driven development. It was then that I started to understand what Chris Pine meant when he talked about “growing” a program. With Agile there was an emphasis on getting started, but mostly I felt it was about being (and staying) flexible. When the sun moves, so does the stem.
Halfway through the course we began our first projects with the instruction to write our user stories in Pivotal Tracker before we began. We had talked a bit about user stories and how to write them, but I was still in “build” mode. We drew out our ERDs (entity relational diagram — basically how you plan on setting up your database) and I was super excited to get started. Since I essentially planned out what my database and models were going to look like and I thought I knew what features were important, I filled my Icebox with todos.
…I might as well have typed in my grocery list. Granted, I had wrapped it in the syntax they taught us — “As a breakfast eater, I want some turkey sausage, because sausage with breakfast rules but I have 3 weddings in the next 3 months and I have a dress to fit into,” but I totally missed the point.
A user story is about user value.
Does the user care if I set up my database? No, not really. Do they care if I set up user authentication? Not in the slightest. Who likes signing up for something on a website? It’s annoying and awful. What value does the user get from a “Log In!” link?
So I deleted all of my stories. They weren’t about growing anything. They were about building my blueprint. And speaking of blueprint, I threw out my ERD, too.
I started asking “Why?” everytime I wrote a story.
“As a user, I want to join the site, because I want to log in and out.”
Why? Why would a user want to type in their personal information to log in to my website? If I couldn’t articulate an answer, I knew my story was wrong.
I became very curious about writing good user stories. After some googling I found this article that helped me immensely.
In one of the comments the author (Jonathan Berger) gave an example of a user story he would write and I used it to craft all of my stories from then on.
Title: User should be able to add item to cart.As a Shopper
I want to put items in my shopping cart
Because I want to manage items before I check outGiven I’m a logged-in User
When I go to the Item page
And I click “Add item to cart”
Then the quantity of items in my cart should go up
And my subtotal should increment
And the warehouse inventory should decrement
I loved this format and it really worked for me. At times it was far too verbose, but its pros made it worth it.
The title made it clear what the feature was and made for simple, clean commit messages. This is where I would have stopped previously. Nowadays I can’t imagine writing a story with so little information. No wonder I felt so lost and frustrated with my first set of stories.
The second part states who the user is (perspective: you are NOT your user), what they are trying to do (what the feature is), and why they are using that feature.
The third part was my favorite and gave me a lot of value as a developer. It describes what kind of user they are, the context in which they are interacting with your site, an action they take, and the results of that action. Written this way, it guides you. Does the context exist yet? Does the user type exist yet? Can they perform that action? Does that action produce the results the user expects?
Once I started writing my stories this way a magical thing happened: I was writing shorter, tighter stories. I let my stories guide my code. If stories were too big, they naturally started to break down. As I started developing, the program started telling me where it needed to go next, where the next bit of user value lay.
All stories had user value. If I completed a story, my site was visually and interactively better and more mature than my previous story left me.
I spent an ENTIRE evening writing my first set of stories. At first I kind of panicked spending so much time on them, but it wound up being worth it in the end. My stories, app, and codebase were all growing in tandem. My 7 original stories grew to over 20, and I was committing code left and right. I always knew what I was going to work on next. I wasn’t distracted or worried I would forget to do that one thing (so I better switch gears and do it now.) If something came up, I would write a story, and forget about it until my current story was done. I was trusting the process and I was flying through features.
Such thought and care going into writing these stories makes it hard not to think of the whole process as an art. It’s not easy to write a good one and I still have a lot of story writing skills to grow (I throw away more than I keep,) but in the end I truly feel like the ones I kept for this project are mini pieces of art… or at least something to go write to Medium about.
Feel free to check out my stories and/or the resulting (growing!) app.
