How do I get started on writing a user story?
X asked, “how do I write user story for this?” In this article I break down the advice I gave him.
I was asked recently for some advice on writing a user story by someone who was relatively new to the technique; I’ll call him “X” to spare his modesty. It was in relation to an online course I created, so I don’t have any real context information, but I’ve seen enough of these types of requirements to be able to provide a few general “pointers.”
Once I’d given the advice, I decided that it would be useful to “show my workings” as it might be helpful for other people who are presented with similar situations. So, in this article, I will share the initial request and how I went about answering it.
When I looked at the example, it struck me a typical situation. The source was a vague aspirational statement about some functionality that is desired, but it really needed to be shaped into something that a software development team could begin to discuss and, ultimately, deliver.
Here’s that request…
“How do I write user story for this? Data with gaps must be exposed to appropriate exception management queues for an operator to clean/fix”
As you can see, the request was pretty light on detail, but that’s OK. Everything has to start somewhere and, in my experience, that’s a pretty typical level of detail for a new piece of functionality. The typical product backlog is littered with one-liners like this. They’re not real user stories, just placeholders for future work. That’s where we come in; our mission is to take that vague one-liner and find a way to develop it into something more tangible and valuable.
Here’s the first bit of advice I gave.
“I would start with the user, so, unless you know their real job title, maybe go with something like “As a Data Quality Administrator.” Then try to state what they’re trying to do; perhaps “I want to see data quality issues in my queue” and why they want that, “so that I can correct the missing data.”
Here I’m suggesting that X reframes that words that he’s been given into the most commonly used user story format. Now, this is not a “magic bullet”, but I thought that would help X to break his “writer’s block” and get him started on the problem, as often the first step is the hardest one to take! Secondly, I thought that the three elements of the common format would expose the things that X needed to investigate in more detail.
And that nicely gets us onto the next bit of advice I gave, which is all about detail.
“This is obviously a very simple reading of the question; in reality, I’d expect you to have multiple user stories based on the lifecycle of an issue, starting with identification of gaps, then delivery to a queue and finally the resolution of the issues.”
Here I’m suggesting that X needs to understand that the user story he’s got so far is what we would often call an “epic.” It looks like it’s a bundle of “needs” and probably conceals all manner of detail within a simple statement.
I’m suggesting that X really needs to understand the end-to-end process and that this will reveal multiple user stories based on each step of the process. If you are developing software to support a business process, mapping the process into a series of steps can help you create a structure for your user stories. Mapping out the basic steps can reveal a set of user stories that can come together to deliver the goal outlined in the “epic.”
The next bit of advice I gave was based on how to identify further user stories.
“There are likely to be identification rules for different types of data quality issues that could be split into specific user stories. You may find there are multiple queues and staff involved, in which case you’ve got more possible stories there around who gets what issues and in what order. You will probably have specific requirements for the end user to see information about the issues; these may present further opportunities to break the requirement down.
If I was asked to do this analysis, I would probably flow chart it out first, then look at the steps involved, and the different paths issues may follow; it’s likely that these will be your user stories.”
Here, I’m suggesting that, going beyond the basic stories identified by mapping the business process, there are a series of things you can ask yourself to break down your stories into smaller pieces of work. The eagle-eyed amongst you will notice some of the tricks that make up the SPIDR technique.
I like to think about the SPIDR technique as being a series of lenses with which you can examine your user stories to find discrete aspects of the work that can be split out and developed separately. I can see that in my advice to X, I’ve suggested looking at Paths, Interfaces, Data and Rules as areas where he may be able to find user stories that can be broken out and played independently. Obviously, each new story identified can then be subjected to the same process to see if there are more user stories hidden within!
I notice that in my suggestions I’ve missed out two elements of the SPIDR acronym: Spikes and Interfaces. Spikes would tend to emerge during discussion with the development team as areas of uncertainty are identified and need to be explored, so it’s natural that I didn’t cover them here. I’ve also missed out Interfaces because I don’t really understand the domain that X is working within, so I’d expect those kinds of considerations to emerge as he works through the end-to-end process.
One thing that I think I should have emphasised more, but assumed was an implicit part of the advice I gave, is the need to discuss the functionality with the end users of the process. I wouldn’t attempt any of those steps without observing the current process, talking to stakeholders about what they are looking to achieve and discussing how best to meet the needs of those doing the work. I fully expect that X will have to have to have conversations with his end users to understand the process at a fairly low level.
So, there you have it, a few steps that should help X to get started breaking his epic down into something that a software development team has a chance of delivering. There’s nothing worse than staring at a blank page, so if you find yourself in the same position as X, I hope that you will find this advice useful too.
The last thing that I said to X was a few words of encouragement. Getting started with any requirements gathering can be daunting, but X has shown that he can see when he needs help and wasn’t afraid to ask. Software development is a collaborative process so the more time X can spend talking to his team and end users, the better his user stories will be.
So, let’s summarise the three steps I suggested.
- Use the common format for the user story to understand if you know who the users are, what they’re trying to achieve and why they are trying to achieve that end.
- Understand the end-to-end process, mapping out the steps to reveal a framework of user stories.
- Take that framework and break down the stories into smaller elements using the SPIDR technique.
Those three steps should be enough to get you going on pretty much any bit of functionality that you might need to create, but most importantly, remember to keep talking to your end users!