Middleware developers often have a tough time writing clear user stories because unlike consumer software, middleware rarely has clear users. Developers may wind up either using the same vague “API Customer” user repeatedly or dropping the “user” from their stories entirely. But having a meaningful user in mind for stories can prevent a lot of problems. Here are some creative ways to use personas as your users for middleware.
The “user” in a user story value statement gives us information about who the user story is for.
As a <type of user>,
I want <some feature>,
So I can <have a desired outcome>.
Even outside of middleware, many product owners choose an overly simple “type of” user.
As a <name of product> administrator
As a <name of product> user
Or maybe
As a sales manager
As a sales representative
While these examples go a step beyond “as a customer” or “as a user,” they still tell us very little about who the user story is for. There’s a better approach: using customer personas.
A customer persona is a written description of one potential person (or group of similar people) whose problems we want to solve through features and user stories. Personas represent customer archetypes, not stereotypes. A customer persona can be a product user or sales representative, but we put more detail into who this specific person is so we can build meaningful scenarios around how they’ll use the product.
Sometimes personas are based on real customers and have in-depth details.
· Melissa is a middle manager at a large corporation, has an administrative assistant who manages her schedule, and has salad delivered to her desk every day for lunch (with the dressing on the side).
· Patrick is in sales, works remote a lot, uses his phone to check his email, and has two children and a dog.
I’m generalizing a bit, but you get the idea: lots of detail.
When we talk about delegating calendar access, we can picture Melissa. What does it feel like to be Melissa, and what are some of her problems (besides getting salad dressing on her keyboard)? What if she doesn’t want her assistant to see the details of certain appointments? What happens when she and her assistant enter an appointment at the same time?
When we talk about devices, we can talk about Patrick. How can he spend more time with his kids while still staying in touch with his clients? Does he want all his client information accessible on his phone?
You probably don’t need personas as detailed as Melissa and Patrick, but understanding your customer’s needs and problems gives your “type of” user a clearer voice that makes it easier to build the scenarios that become your features and user stories.
But we’re talking about middleware, aren’t we? So, do personas have to be people? No, and that’s the trick.
Personas exist to make clear the business case for the scenario. The final deliverable might be a product that sales representatives use to sell devices to customers. If your team makes the APIs this product relies on, who is your customer? Traditionally, you would start with the customer purchasing the device, but your API isn’t solving their problem. You could consider the sales representative your customer, as they are the one using the product, but they’re demanding improvements to the product, and that doesn’t specifically relate to your API. The API enables those improvements, but the sales rep doesn’t care about that.
In this case, your “customer” is more of an “actor” or entity whose problem is solved by your team’s work: any product, app feature, or even group of apps that uses the API. Or alternatively, your customer could be developers who use your API to build and improve their products. Your customer is the one who cares about the scenario and its outcome, even if that’s not a person.
Such a persona needs different details to be relevant. What problems do these developers or products have? Products don’t have delegates or eat salads or have two kids and a dog. So what details do matter?
The product’s users probably access it on multiple platforms, like a desktop and mobile device. They likely need their products to be secure, speedy, and housed in the cloud. Also, each product will likely have its own specific issues.
Here are some examples:
Example 1
As the customer data lookup feature <X> for product <Y>,
I need to access customer name data,
So I can look up customer information based on customer names when my sales
representatives do not have access to the customer’s phone number information.
This example is a request for a change in the API from a specific product team to support a new feature. The product team provided information on their feature and what the change will be used for, which will help the API development team to better understand and implement the request.
Example 2
As a product developer using <API X>,
I want to be assured the API passed <Y> security requirements,
So I don’t have to worry about any security holes in my product caused by <API X>.
In this case the product itself doesn’t “care,” but this work item makes things easier for the product developers. This improvement in the API is independent of any specific product or developer using it.
To summarize, the “user” in user stories doesn’t have to be a person. It just needs to be an entity with real and complex needs, and it needs to be detailed enough that the team can imagine it clearly. A meaningful user clarifies the purpose and function of the work the user story is asking for.