I make stuff.

Menu

SCRUM User Stories, Part 2: User value over business value?

My last post about User Stories and putting the value for the user first in any product decision generated some great discussion on Twitter. As with anything there are some varying views on the topic, and as one example I was pointed to Liz Keogh’s post on user stories.

Liz argues that User Stories should be better named “Stakeholder stories”, as the things you build are addressing the needs of varying groups of stakeholders, only some of which are the end user.

In the creation of any product there are of course many stakeholders who need to be satisfied: the CEO, shareholders, investors, marketing people, the legal department, and so on. In the design of the business, of course the internal stakeholders have the most important requirements. What sort of market are we going into? What segment will we serve? What problem or user need do we attempt to address with this product?

But when you start designing the product that the user will have in their hands, then the user needs to be at the heart of that design solution. Here, the user needs have to come first.

But what about all the stuff that you have to build into products that users don’t want, or even hate? Stuff like CAPTCHAs during registration processes, or advertisements? If the user’s needs come first, why does this stuff exist? To answer this, let’s take a step back and look at where user stories come from.

User Stories are not immaculate conceptions: they don’t just appear out of the blue, but they are thoughtfully created to address needs of the product and the business. On other words, they are derived out of the product vision and the surrounding business model.

If your business model involves monetisation through advertising, then you have a problem to solve: “how can I enable advertising in my product?” It’s clear that the user is not at the heart of the decision to enable advertising, but business models are complex and have to satisfy many stakeholders and solve many problems. At the business strategy level, the end-user is only one of multiple players, and the user doesn’t always come first.

So you have this problem: you have to enable advertising. How do you solve it? Do you slap a full-screen takeover banner for some random personal hygiene product on your start screen? Probably not. Do you enable Google AdWords to show advertisements relevant to the content in a meaningful way? Getting warmer. Do you study the user’s interaction on the page to determine where the advertisements should be placed and how they should be visually displayed to ensure that users understand what is a sponsored link and what is your own content, to avoid frustration and confusion from the end user and maximise the meaning and value they get when they interact with the advertising? Better still.

What is at the heart of each of these decisions? The user. This is where the user comes first – in the design of the solution to the problem. In the User Story.

User-centric design doesn’t absolve you (regrettably) of the need to be aware of the business context or the constraints of your business or industry: it merely proposes that the user is at the heart of how you solve your product problems and how you work with the constraints. Keeping the user at the centre of your user stories by insisting they start with “As a User…” helps you stay focussed on the people who will be interacting with the stuff you’re building.

5 thoughts on “SCRUM User Stories, Part 2: User value over business value?”

You wrote, “At the business strategy level, the end-user is only one of multiple players, and the user doesn’t always come first.” This is the perspective from which I’m writing. I see no reason why the business strategy shouldn’t play into stories. If that *leads* to usability, fantastic, but I don’t think that usability should automatically be our first consideration. I prefer to pull usability from the business requirements, so that it gets the appropriate focus when it’s important, while allowing fast feedback on other, more risky areas when it’s not.

A large number of the projects I’m coaching and collaborating with don’t even have UIs, and are used by other systems, or are simply a reworking of existing systems to enable better performance or cost benefits. Some of them have administrative UIs, for which the direct user isn’t the most important one. Others have logs; a different type of UI again. Most of the products I work with are internal; delivering their benefit to someone else in the organisation, rather than the user who fills in the data.

I’ll provide another example from Dan North to illustrate this:

As a doctor, I want *other doctors* to fill in patient’s details so that I can access them again later.

If the only projects you work with are user-centric, then even by considering all the stakeholders you’ll end up with stories that want to deliver something to the users, and that’s the right thing to do. They’re not the only type of project. Would you normally phrase stories around the kind of projects above using “As a user”? If so, I’d love to see some examples, please.

In terms of the business strategy playing into the user stories: the way I see it, the business strategy/business model defines the broad problems you need to solve, and the constraints (monetisation, platform, technologies, etc) within which you need to solve them. A User Story is a single, discreet problem that you wish to solve. So the business strategy does play into the User Stories, in that it is the primeval ooze from which they are created, and it is one of the factors that lets you prioritise them. But before a User Story goes to be designed or developed, I like to see this transformation take place to User Benefit. The requirement is still there, and the constraints still exist: but there must be a way to solve the problem in the way that leaves the highest delight factor possible. It is finding this delight factor, in every solution, uncompromisingly, that results in a delightful solution.

To your second point, the more we discuss I’m not sure we are disagreeing on the level that we supposed: perhaps we just disagree on the definition of ‘user’. Every product, whether internal or external, has users. A ‘user’ doesn’t necessarily need to be an external, paying customer. If you are building an internal API to transform and feed data to another team, then your ‘users’ are the people who interact with that API. If you are writing a script to build logfiles, then your ‘users’ are the people who read the logs.

If you are building an internal data API, maybe it’s fine to swap “As a User…” with “As a developer…” – as long as it’s clear to the team that you’re talking about the people who will use that API. In my experience, projects like back-end APIs seem to be where user-centric design is lacking the most. If an API meets every business need and transmits every piece of data, but the ‘users’ of the API (the developers) pull their hair out when trying to program with it, was the API successful? If you had an open market of APIs, and your internal customers could choose a different one, would they?

To your example story above: “As a doctor, I want *other doctors* to fill in patient’s details so that I can access them again later.” What is wrong with that story? If the doctor is the actual *user* of the solution, and that’s what they really want… how to solve that problem is what the story is all about.

To me, user-centric User Story creation/design is about focussing on solving the problem for the user who is going to consume the solution. Maybe I have the luxury of working on a single user-facing, user-centric product (maps.nokia.com). But I still believe that knowing and understanding who the real user is of the system, and designing for them first, will lead to the most delightful experiences.

They might be the most delightful experiences, but they won’t necessarily be the cheapest or simplest. If we *need* to engage users through delightful experiences then I’m all for it, otherwise I’d prefer to do less. That way we get feedback more quickly, with less investment.