Don’t write user stories based on your UX designs.
“A user story is a promise for a conversation.”.
Alistair Cockburn
I love this definition, in my opinion a user story is in fact an artifact to collaborate inside the team to define what to implement for the user/customer.
User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
http://www.extremeprogramming.org/rules/userstories.html
In the majority of teams I’ve been working on, user stories are the output of a process between some PO’s, BA’s or UX’s that fit inside a card all the requirements they think.
Later at some point the deciders talk with the dev team (QA’s, devs, etc) to ask them how much time do you need to do this.
This is not collaboration, this is just a miniwaterfall approach.
I think this approach has a very bad effect on the product we create, builders are usually the people who know more about the product, because they are building it. So don’t use them just to give a number to a story, let’s involve them in the ideation.
Written communication is much worse than talking, trying to put all the details in a document it’s simply less effective than a conversation. So for me, this is the interesting part of user stories. They are more a log of decisions than a predefined set of steps to achieve a big plan.
Then, if we should collaborate to fill the whole story how can we start, just by a title something that describes what the user need also identifying the persona:
“As a [persona], I [want to], [so that].”
So to start, let’s write a first set of ideas related to what the user needs under a certain problem. Probably, you will need to understand the user, so it’s a good idea to think about the personas. In fact, this is the Lean Inception Method.
After some workshops you will have a set of features interesting for you and with them prioritized, you can start using those things as epics to split in some user stories.
Under those ideas you can have different tasks, spikes, investigations to have more info and start writing some stories, just with the problem the user wants to be solved. The minimum to allow you to write stories.
To continue with the user story, you don’t need to wait for your design to be completed for the whole feature. In my opinion, the user interface is good to be also improved with the feedback coming from the team, showing small increments and adapting easily to the problem.
So yes, we can start developing things without a signed-off design, we just have to not put too much effort in our frontend solutions, people can imagine things, people when they see things working even ugly things they think on how this could be and focus on the behavior.
Even more, we can change the user story, split it in other stories, fix things while we are developing, it’s a framework not an inmutable law.
Working software is the first measure of progress, but also is the easier way to obtain feedback. Final designs are great, but there is no sense to wait one month to have them ready to create a story that is a map of each page of the design. Let’s start collaborating with temporal mockups, even with nothing, showing designers results from working software, and make them to think. Let’s create our design based on the feedback of our small increments of working software.
No worries, software is easy to change (if not we have to improve our dev skills), so let’s use that to iteratively improving. Also don’t think that deployments are equal to release, you can deploy to production continuously and not showing your intermediate steps to your users (CI/CD).
I know that sounds scary, but the order is not this:
Create the UX designs
Fill all the details in the user story based on those pages
Use the user story as a journal of what we have been discovered and decided about the user story, as a framework to work collaboratively.
So let’s start by writing the user stories without design, without thinking on the details of our application, just from the point of view of the user/customer related to the problem to solve. If we cannot do this, let’s create spikes to understand it. If we cannot easily access our customer, let’s try to put that hat in our heads, a lot of times we are also customers.
Let’s add some acceptance criteria to our user stories based on what users require, this is what I love about BDD. Having conversations around examples of scenarios of what users require and creating the ubiquitous language.
I like to use gherkin to write them in our user stories during those conversations, and I like to define them as examples, not as generic algorithms to solve the problem. I’m not saying anything about using cucumber or any other tool to use directly those acceptance criteria as automatic tests. For me, the value it’s much more about having those conversations based on examples and a formal language between different roles in the team.
Then you can describe one or more business scenarios, meaning the overall behavior you want to obtain with the user story.
Scenario. For instance, you can describe a scenario like that: “The Visa Cardholder use the Visa Classic for paying”
Given. Use the given keyword to describe the context for a business behavior. For instance: “I am a Visa Classic Cardholder “
When. Describes the action required in order to produce the output, i.e. “I pay with my Visa Classic”
Then. Describes the expected output, i.e. “My Visa is accepted”
https://marcellodelbono.it/given-when-then/
Once we think we have finished, let’s rethink about our user story, is it too big to be implemented or not. Too big depends on the team, but put the pressure to have stories smaller, a pair of days to be implemented. If the story it’s too big, let’s think on their acceptance criteria, can a subset of them be considered another smaller user story?.
So you know, split it in more user stories (vertical slicing).
The point of not having the designs is to abstract the acceptance criteria and avoid adding details related to the specific implementation there. All the roles in the team discovering what to solve and how to do it, this is a user story.