Tips for writing user stories

 

Essentially, user stories are a vehicle for getting stuff done. We say what we want, for whom, and what the end goal for each request is. The product team will then take said request and assign an estimated value that is used to evaluate delivery. When user stories are nailed on, it can be like poetry in motion. User stories are fantastic, as they are a great way to simplify a feature and can help set priorities when ordering tasks. It also stops the old system where the less tech savvy people tell experts on how to do their job or, as I like to call it “Lying”. Because the engineer who would actually build  your request will look at what the intended outcome needs to be and just build to that anyway. But the basic “As a ….I want …. So that….” user stories alone can leave your development team wishing for the ‘good ole days’ where they ignored incorrect heavy on detail requirement documents. So, here are some tips for writing user stories so that they don’t become ambiguous forgettable half-baked statements:

 

  • Think about all the personas involved

Before you write anything, list every persona of who will be using the product. Sometimes it will feel like you are writing the same user story but it’s still good to flip it to the other side and acknowledge where the similarities are rather than assume.

 

Not just the big stuff, start off big and break them down.  I like to physically draw out everything I am thinking about and break it off into sections.  Each section should have a reason to be there, if you can’t write a story for it, then it’s not needed. Once I know the collection of user stories for a feature I then create an epic and file each task in the feature set to that epic. That leads me onto my next point quite nicely.

 

  • Epics, just use them

Epics are stories that need more detail to complete, that usually means they need to be broken down. Yes, having user stories for every action is nice but they need to be structured, otherwise testing and development becomes more challenging. Take a feature set like having an account page, there are tons of stuff here: “Input username, Input password, Forgot password, Create an account, T&C’s, Log out” the list goes on and on. Each of these tasks could require quite a lot of stories, so for planning purposes wouldn’t it be better to have an Epic titled “Account Management” where each feature related to said epic could sit and link accordingly.

 

  • Say what “done” looks like for your story to have a happy ending

I always put a Definition of Done (DOD) in my user stories. 9/10 times the DOD is “We are able to start work on ticket XXXX as a result of this work” because usually there is a chicken and egg scenario with user stories, X is dependent on Y and so on. But for when there is a marketable product feature, actually call it out “DOD: It has passed QA, we have signed off on it, this feature is Live, users are able to enjoy this feature, and has been stable for 12 hours”. Amazon has gone so far as to include a definition of done metric for each and every project.

 

  • Call an edge case an edge case

I am sure we have all been there, figured out a user story that we are so passionate about we would fight tooth and nail to get it in a sprint. But only then to realise the actual benefit of this user story is only felt by 0.2% of your audience. Acknowledge the scope of people that will actual benefit from your user story. I am not saying don’t write them, I am saying acknowledge the edge cases and prioritise against them.

 

  • Acknowledge a Spike

If someone says “we do agile, but we don’t do spikes”, that is a sign of concern for me as they are effectively saying they know how to do everything ever, and that they never need to do exploratory sprints to deliver anything. Once someone has reviewed and valued my user stories I like to ask them what Spikes will they be doing and document it so who ever is scrum mastering will know that we have to have a time boxed period to figure something out. This makes Kanban more efficient.

 

  • Talk!

A user story should be an invitation for a conversation, not for people to work in isolation. Talk to each other, and make sure you attend stand up and sprint reviews. A good scrum master will have some form of ceremony for user stories to be discussed but don’t rely on that to be the only forum for user story discussions.

 

 

What are your tips for writing great user stories? Leave a comment below: