Short answer: Explain the what, and why, but not how; cover the edge cases; break or adapt templates where necessary.

As an experienced user story writer, let me tell you that it’s completely okay to break away from the user story mold wherever it’s needed. The “As a user(or persona), I [want to], [so that]” template is a great starting point for people new to the user stories game. However, there are places where this completely falls flat.

Here’s why: Sometimes users describe the app you’ve developed as “clunky” and “not slick”. However, writing a user story that states “As a user I would like the app to be more responsive” would not cut it for an engineering team trying to fix the performance of an app (which could involve improving API response times, frame rate drops, or layout shifts).

The point of the user story does still hold: empathise with the end user. The template is one way–a standardised way–to get there, but typically doesn’t fit well with the engineering/design team’s needs, and often misses the point, in favour of the process.
In this post, I want to walk through the core idea behind user stories, that should help you to write your own stories more effectively by cutting out the noise.

What, and Why, not How

Focus your user stories on what you want done–changed, added, fixed. Some examples:

• The sign up process needs to implement a second factor authentication using phone numbers since our users don’t use emails very often.
• Our transactions list tab needs to respond faster, ideally showing up-to-date data that was fetched in the background.
• Add support for exporting reports in an Excel format.

Of course, this is only a part of the whole story–we will build up to the rest in the coming sections. However, so far, this is an accurate (although simplified for the sake of brevity) capture of the way a story might communicate what needs to be built–without any of the noise.
Based on your context and the way your team likes functioning, you would go a bit more detailed on these fronts, explaining the functionality a bit further. For example, you could elaborate the third example in the following way: “Add support for exporting reports in an Excel format. Users are okay to wait and receive these reports via email. However, they expect a granular selection of fields in their reports that map into columns in the exported Excel”.

Next, the “why” adds important context to the change you want done. Let’s evolve the previous examples:

• The sign up process needs [...] emails very often. This is an imperative for further sales to happen to corporate customers where a second factor of authentication is mandatory for all software used within the organisation.
• Our transactions list tab [...] background. Analytics data gathered in the app, and on the website indicate that users, upon completing a transaction, look at the transactions tab 78% of the time in order to confirm a successful transaction.
• Add support for exporting [...] in Excel. This need comes from customers’ tracking and analytics teams that prefer to look at their raw data so that they can fit it into their existing reporting workflows.

With this added context, it becomes immediately clear to any reader within your team that the first story is the most important since it is actively blocking sales to new customers, whereas the importance of the other two are up for debate.

Forget the How

Now that you have the two main items down, let’s focus on one that you shouldn’t worry about (or even write). That is: How do you go about achieving the change? The biggest reason why is, while conceiving the feature, you can’t limit your thinking by what state the designs or codebases are in.

This isn’t to say those aren’t practical considerations–they absolutely are. However, that can come as push back from those who need to build out the change in question. This is where it’s important to stick to user empathy–the user doesn’t care about technical debt, or internal priorities etc. They care about the change–no holds barred. So, at least when it’s your turn to document it, ensure that your imagination isn’t constrained by practical limitations. What gets built will involve those practical limitations due to constraints of money, time, availability and factors (possibly) out of your control.

Another reason to forget the how: The development/design team might anyway be better suited to navigate the best way to build the change in question.

The Devil is in the Details

Now that the basics of What, Why, but not How, are out of the way, there’s another critical element to touch upon–sort of the icing on the cake–the details, especially around the edge cases. Let’s explore our original examples with some questions one might want to explore:

• Two factor authentication is great, but how does a user who has lost their password or phone get it back? How do existing users get migrated into the new system? Is this opt-in for a certain period after which it’s mandatory? Should the cost of sending SMSes result in an increased billing to customers who opt into this system?
• If the background fetch of data fails, but an older copy of transactions is present on the screen, is it okay to indicate to the user that the data they are seeing is not up to date and may need a refresh of some sort? Or should the screen not even show the original data?
• What are the limits that should be imposed on the Excel export? What if the data is of the order of hundreds of thousands or more? Should the files sent to the user be split up instead?

Answers to such questions may not come to you right off the bat. But without them, it’s impossible for any team to start conceiving of solutions to the change you are proposing. Further, your team would have specific questions to think about compared to another, that can only be learned by experience. For example, an e-commerce app would really care about SEO optimization so each change might need considerations there, versus an app that deals with transactions would have a much higher emphasis on API response times.

Engage and Evolve

This post is mostly to highlight the core of what should be covered–with some simplistic examples to anchor the explanation. Some things will work for you and your team and others won’t–even within the same team, as your team scales and other teams such as QA, analytics, and such get involved. The whole point of agile is not to settle into a template, and instead change as change presents itself.

Have fun out there.