Dude, where’s my user?

When crafting user stories, is it OK to name some non-human part of the system as your user? You may be creating requirements masquerading as user stories.

A common user story format

You are probably already familiar with this standard user story format:

As a <type of user>
I want <some capability>
So that <some benefit>

During the course of working with various development teams, I’ve run across stories like this more often than I would have imagined:

AsĀ the database, I want to have a Customer table, so that there is a place to store customer information.

or:

As the system, I want to have an account object, so that account information can be seen.

The examples above certainly follow the standard format for user stories, but that doesn’t necessarily mean we’re getting all that we can from them. Either could be re-written as a simple requirement:

The database shall store customer information in a Customer table.
The system shall store account information in an Account object.

What we have here is a case of requirements masquerading as user stories. Note that both the faux and true user stories specify what is to be built. The difference is that the faux user stories leave out important information that true user stories convey, namely who the user is and why the story is being implemented.

These are important pieces of information, as they aid in determining that we’re building the right thing. In short, if a developer knows why something is to be built, and for whom, then he or she can make more intelligent decisions about precisely what is needed. And this can result in building something that is more useful and less expensive.

So if a simple requirement expresses the same thing as a so-called user story, why go to the trouble of bending the requirement into the shape of a story? Why do we see as many examples of faux user stories as we do?

My guess at the most common reason is that developers have been taught, or have led themselves to believe, that all features of a product must be expressed as user stories.

Another reason may stem from claims I’ve heard fairly often that are typically expressed as something like, “The work I do doesn’t have a user.”

Scrum says nothing about user stories

Scrum is the most commonly used framework for Agile development. And contrary to what many have been taught, Scrum says nothing about work items being expressed as user stories, but instead refers to them generically as Product Backlog items. Additionally, Scrum does not even require that all backlog items be of the same type or format, so a mix can be perfectly acceptable.

Now, to be clear, I’ve got nothing against user stories. I think they’re a very effective way to express the capabilities a system provides, and I use them almost exclusively when doing development work. My objection is to time-wasting efforts to express all work to be done in user story format.

Depending on your development environment and culture, you may be most comfortable populating your Product Backlog with a mix of true user stories and technical tasks.

My personal preference is to put only true user stories in the backlog, and to let any user story spark the creation of any necessary technical, under-the-hood stuff. But to do that, I have to engage in a mental exercise that I call:

Dude, where’s my user?

First, when I say “user” I mean some human-type person—not a data structure, a software component or other aspect of the system being built or a system that uses it.

User doesn’t necessarily mean a person interacting with some user interface. It means the person using your product, whatever it is that you produce. So if, for example, you produce web front-ends, your user probably is interacting with a user interface, and you should have little trouble identifying that user. If, however, you produce an API for a web service, your user is likely to be another developer, and you can write your user stories accordingly.

If you can’t easily identify one, you need to ask yourself, “Dude, where’s my user?” Because there probably is one out there somewhere. You may need to follow the path from your product through one or more other connected systems, until you find that person.

And If you can’t ultimately identify a user who benefits from what you are about to build, perhaps you should reconsider whether you’re building the right thing. Products are ultimately created for the benefit of human beings, so if you can’t find those people, either keep looking or stop building.

That bottleneck may be right where you want it

Mere mention of the word “bottleneck” is often enough to generate a flurry of proposals on ways to eliminate it. But every system has a bottleneck, and yours may be right where you want it.

A useful definition

Examples of bottlenecks, both at work and out in the world, abound. Work piles up on the desk of a co-worker who is out sick. Traffic comes to a standstill on the freeway while driving to and from work. (The most common one in my commute is a particular spot on Highway 101 north of Novato where three lanes turn into two.)

But some things that we think of as bottlenecks, aren’t. In a work environment, it’s common for people to label anyone or anything that is preventing them from starting their own next work task as a bottleneck.

A more useful definition of bottleneck comes from The Goal by Eliyahu M. Goldratt:

“A bottleneck is any resource whose capacity is equal to or less than the demand placed on it.”

That’s a powerful statement. And it’s the “equal to” part that I find the most interesting. If you turn the definition on its head, you can express it as:

A bottleneck is any resource with no spare capacity.

The bottleneck is a pacesetter

It’s convenient to think of a software development environment as a chain of dependent operations (e.g. requirements gathering, design, development, testing, deployment).

The bottleneck in your software development environment is the operation with no spare capacity with respect to the demand on your chain of development operations as a whole. If you measure the rate at which finished product is leaving the end of the chain, you can identify the bottleneck by finding the operation whose production rate matches the system’s rate.

In other words, the bottleneck operation sets the pace of production for the entire system. And that’s why I find it useful to refer to a true bottleneck as a pacesetter.

Deciding whether or not to eliminate a bottleneck

Your system is going to have a bottleneck somewhere, and fixing a bottleneck at one operation will have the effect of moving it to some other operation. You only want to move a bottleneck if you don’t like it where it is.

So how do you know if your bottleneck is in the right place? Just take a look at the rate of production of your development environment as a whole. If delivery of finished product (e.g. features, user stories, or whatever units of work you use) is keeping up with demand, you’ll likely want to leave the bottleneck where it is.

And how do you assess demand? In a software development environment, demand might be determined by your marketing organization (i.e. “We need to have features A, B and C delivered by the end of March”).

A bottleneck side-effect

A development environment that is keeping up with demand, and that has a well-managed bottleneck, will also exhibit what is often perceived as an undesirable trait: Not every operation in the development chain will be occupied 100% of the time. In other words, some people are going to appear as if they’re not working at least part of the time.

But this is intentional. If the bottleneck is the pacesetter for the entire system, then all of the non-bottlenecks will, by definition, have spare capacity which can be used, when appropriate, to make sure that the pacesetter operation is never starved for work.