User stories about one and the same functionality for two different roles

Question

My team is building a solution where a mobile app communicates with a backend. I need to describe functionality where the communication between the app and the backend is optimized according to some rules that work for both the client (mobile app) and the server (backend). This optimization will be mostly developed on the client side as it's the one collecting data and then sending it to the server and thus responsible for optimizing the amount of data sent to the server.

Now the optimization is important for both the mobile app and the backend. The reason is performance and scalability, however there are different aspects for both.

For example, for the the users of the mobile app, the main need to reduce the sent data comes from the fact that it might be on a potentially slow network and cost. For the operators/owners of the backend, the main reason is scalability and economics; the amount of data sent by multiple clients that needs to be processed and also simply because in the end, it doesn't need all the raw data gathered by the client to do its job.

Thus, I wonder how best to express all this; should it be one story or two stories where each story has a different role and value?

I also wonder if this is a story at all; ultimately the need for the backend owner/operator is to run with as little hardware as possible, to have a low enough TCO. For the user of the mobile app, the main value is to reduce the bill and to have timely feedback from the server. However, I don't even have concrete customer requirements for the end-users, though I do know what rules the transmission should obey and I know that it could be optimized. From this point of view, this is more a design concern than a concrete story. I wonder if this should go as a task in the backlog and not as one or more stories

Answer 1

You can make these valid user stories, but your need to keep them focused on benefits for the end user. For reducing the size of the payload sent to the server focus on the metrics of reducing data size tied to a metric.

In order to stay within the limits of my 2 GB wireless data plan

As a user on a mobile device while not connected to WiFi

I want to use less than N bytes of data when I do Thing X

Where you replace Thing X with an action the user performs. It is harder to craft a user story for the back end. Their main concern is scalability, but why are they concerned about this? Performance. Faster performance means a better user experience. Write user stories that focus on this aspect and maybe even tie it to specific metrics, like how many users you want to support or the expected time it takes to post some sort of data and see it.

Basically you want to make non-functional requirements valid user stories.

Answer 2

This isn't the domain of implementation, but the domain of protocol.

After the protocol has been worked out, using those requirements/desired properties, then stories can be crafted to implement the expected behaviours incrementally in both the client and the server.

When drafting the requirements of the protocol you will need to analyse the requirements of each role/party that participates. The obvious ones are the client and the server. But there are less obvious parties such as the proxies/firewall/networks inbetween, and adversaries attempting to eavesdrop or mess with the protocol.

Answer 3

Engineering costs money, so open-ended statements like:

run with as little hardware as possible

...are too incomplete to be stories. Running on as little hardware as possible would be the task that never ends. It may very well be the operator's goal to run on as little hardware as possible, but that is probably a local optimization. If the infrastructure manager has your team spend $2 million of engineering effort to reduce their hardware costs for this application from $40k/year to $10k/year, said manager is going to get handed a box for their belongings and escorted out. You need numbers. You need a spike.

If you have load tests or metrics showing you can run X number of concurrent users on Y amount of hardware, and Y hardware costs Z dollars/year to run, then you can run some experiments. You might decide to stub out enough of your program that you can send controlled amounts of data during your transmissions, and run some load tests. How much do you need to reduce the data size by in order to get a worthwhile reduction in hardware? If you need a 90% reduction in data size to get rid of one node in the cluster, is that even worth doing? Is that even possible to do? Or maybe a 10% reduction in data size will translate to needing 10 fewer nodes in your cluster, and that might save $20k/year in your environment. Once you have information on what's possible and what kind of benefits you might get out of it, you can make an actual story. Something like this:

As a backend operator

I want to serve x concurrent users on y hardware

So that I can reduce hardware costs by z

Now you have a story that tells us who wants this change, when the change is done, and what the value of the change is. The product owner should be able to decide whether or not this story is worth spending their money on, and what the priority should be. Maybe the lower operational costs will allow the product to be priced more competitively. Maybe hardware is cheaper than losing customers, so the product owner prioritizes a large customer's feature request ahead of this performance optimization task.

The point is, if you have actual numbers to work with, the product owner will know what they are gaining/losing if you do/don't ship this story. Without some rough numbers though, whatever story we come up will be meaningless, and therefore not really a story. Whoever is pushing for this work to get done needs to have at least a little bit of data and experimentation in order to turn those into a story.

Answer 4

This is not a user story: it’s a non functional requirement and it’s certainly common to several stories:

• The users communicate with the app and do not care about behind the scene and how data is transmitted.
• Every interaction between the app and the server is potentially impacted.
• The resulting optimised performance is an emerging effect of the implementation of a lot of features.

Nevertheless, even if it’s not a user story, you need to tackle it appropriately in your backlog. Mike Cohn, the user-story guru recommends to:

• write a technical story, where the user is not the real user but the stakeholder interested in this requirement (e.g. as a mobile subscriber, I want to keep the offline volumes transmitted low in order ro reduce my bill), or
• exceptionally, write a userless FDD feature: [action] the [result] [by|for|of|to] a(n) [object] - the advantage is to lake clear that there is no user behind this item.

In general I’d advise for the first, because it provides not only the requirement but also the motive. And this can be useful when we have to negotiate on trade-offs.

However in your optimisation case, I’d be tempted to recommend the second: there is no advantage to bring in artificially a stakeholder who doesn’t care about such very technical details and who cannot help us to decide between alternatives.

Answer 5

Many streaming services lack a story or simply information on how big the average song or movie file actually is. Many mobile devices support super high hdr, 4k or even 8k now. That´s a problem for many with limited bandwidth thus in need of smaller files you most likely encoded to jpeg/jpg. Tell everyone how much the average user save by NOT having to download very high resolution but still be happy with the quality. By telling when the serverload is highest or opposite, people can avoid slow buffering or loading. If free users share the right ammount of their bandwidth from storing parts of files on their devices, the paying customer will feel superiour and they should too imo.

I hope this can help by any factor. Your solution is very exciting to read about hope all goes well.