TL:DR
User stories are supposed to capture the user’s perspective, yet we disguise business requirements as user stories. Business requirements should be written as business stories to capture the need of the business and its impact.
To the actual gist.
There is nothing wrong with business requirements. There’s always a trade-off. In the age of user-centered design, it feels like we are silencing the business and saying its needs are unnecessary; instead, we run after users pampering and begging them to give us data or to satisfy them. These days there are few conversations about the needs of the business beyond “consider business goals.”
However, the business is solving a problem for our users, and to continue to do so, We have to consider its needs. We shouldn’t be scared to point out business requirements as that — business requirements.
When we do, we should optimize to simplify the experience for our users.
For example, users don’t always think they want to create an account before accessing a platform — you know, as a user, I want to be able to create an account. Half the time, they don’t. And yet, for so many benefits to the users and opportunities to grow as a business, we require them to do so.
So what should a business story look like?
I’ll explain this using the JTBD framework — majorly because it considers the context.
A business story for an e-commerce company might be;
“As a business, when thinking about ways to personalize the shopping experience for our customers, we want them to create an account, so we can have access to credible data to help make that decision.”
For this same story using the usual method, it might be
“As a business, we want our customers to create an account so that we can access credible data to personalize their experiences.”
Taking this a step further and making these stories more effective, we can substitute business for the department needing this requirement.
So then the revamped story would be;
“As a marketing/research team, when thinking about ways to personalize the shopping experience for our customers, we want them to create an account, so we can have access to credible data to help make that decision.”
Sometimes the same story might have different goals depending on the teams that require this feature. In which case, it’s ok to split and have sub-stories which are generally other use cases.
Business story ✅ — what’s next?
Next, we take this story, understand more about the requirements and their potential impact, and figure out a way to simplify this experience for our users.
To do that, we ask questions like:
Does it make sense for the user to sign up before accessing the system? Or can we create an ID to store their data until checkout temporarily?
Should we use the data to create an account for the user and perhaps pleasantly surprise them by asking them to skip the sign-up process as they know it and change passwords or delete the information we have at their request? I don’t know, I don’t know, but the point is we better understand why we are doing these things and can get people more engaged. It also promotes system thinking.
So, the next time you want to create a story, ask who does this benefits — the users or the company.? If it’s the company, what department(s)?
Have you used business or JTBD stories before? How’d it go? If you’d also like to talk more about business, JTBD, and User stories, I’m up for a chat on Twitter or via email.
