On the true nature of agile user story users

I was recently cc’d on an email advocating adding a particular user story to an agile project backlog. Let’s call it the ‘Big_New_EDI_System’ project.

As a Big_New_EDI_System developer

I want to be able to employ a standard router service

So that I can determine using the EDI transaction type, customer data, customer id prefix, and customer transaction date which back-end system to route the transaction to.

This rang really wrong for me. A developer shouldn’t be the user in an agile user story unless you are making a development tool, right?

So I decided to dig a little deeper.

I did a quick survey of all the user stories on the Big_New_EDI_System project. In 100 user stories there were 29 different users. Categorizing them as humans, transactions, developers, or systems, this is what I found:

100 total user story users =

81 developer users, such as ‘BPEL Orchestration Developer’

9 transaction users, such as ‘Order Status Inquiry’

4 system users, such as ‘Big_New_EDI_System’

6 human users, such as ‘Store Owner who has submitted a customer account validation request via our online tool.’

I would say my comfort level at this point was, oh, about a 6 on a scale of 100.

I could see how a system might be a user. But a developer? A transaction? Could it be that 9 out of 10 user stories on the project had been created with invalid users?

If so, what did that mean for the stories themselves, the team’s ability to work them, and their ability to finish the project? And if they did finish, what would be the impact to the nature and quality of the system they delivered? Time for a little pranayama.

If I was going to raise the hue and cry over the possible validity of the user stories on a hundred-plus resource eight-figure project I needed to laser-align my ducks.

I needed to understand exactly what a user story user was.

Today’s rumination is on the true nature of agile users.

In ‘On the true nature of use case actors‘  I described how poorly the use case actor has been defined in use case theory, and attempted a working definition.

The user story email made me suspect that the user story user might be similarly ill-defined. And given the similarities between use case actors and user story users I thought I might be able to leverage some of the same thinking I had employed in analyzing actors.

When I researched agile user story users I found the same kind of slim pickings I had found researching use case actors. There is very little original work on the methodology.  The overwhelming majority is simply parroted from elsewhere, usually without attribution.  What passes for expertise seems very shallow.

So my research approach was to start with work from key signatories of the Agile Manifesto and move forward in time.

Here is what I was able to glean.

Kent Beck (inventor of the term ‘user story’) has a number of wiki pages on c2.com where he and fellow Manifesters Alistair Cockburn, Ron Jeffries and other posters discuss various aspects of user stories. There is no single clear description of what a user story user is – users are generally referred to simply as the authors of user stories. In fact, there is a lot of discussion but little clarity on what user stories themselves are or are not.

Jeffries is the pithiest: “[a] UserStory is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement.”

Jeff Sutherland – co-inventor of Scrum, and another original signatory of the Agile Manifesto, has published a presentation deck called ‘User Stories Done Right.’  But in it he largely borrows the actual user story stuff from one Mike Cohn.

And it is Cohn, Mr. Mountain Goat Software (cool logo and great website), who seems to have emerged as the leading acknowledged expert on user stories. He was a founding member of the Agile Alliance. His 2004 book ‘User Stories Applied for Agile Software Development,’ published in Addison Wesley’s Kent Beck ‘Signature Series’, has become a standard reference. According to the back cover blurb from ‘Applied’ “you’ll learn what makes a great user story, and what makes a bad one…”.  He has since published two other popular books on agile practice.

And we have Cohn to thank for what has become the most widely used template for user stories – it was used in the story we began with above:  “As a <type of user> I want to <feature> so that <benefit>”.

Cohn, who is not only an author but also an instructor and a popular speaker on the conference circuit, is definitely one of the parent-most nodes in the agile IP parrot tree.

So I got ‘Applied.’

What does Cohn have to say in it about user story users?  Let’s dive in together and see.  We are looking not only for explicit descriptions of user story users, but also for descriptions of user stories from which we might infer things about their users.

“What is a user story? A user story describes functionality that will be useful to either a user or a purchaser of a system or software.”

But then rather than trying to describe the difficult-to-describe, Cohn jumps right away to the ‘you’ll know it when you see it’ extensional device of some quick user story examples from the fictional used-for-illustration BigMoneyJobs website project:

“A user can search for jobs.

A company can post new job opening.

A user can limit who can see her resume.”

And he provides two examples of ‘bad’ user stories:

“The software will be written in C++.

The program will connect to the database through a connection pool.”

The users in two of the ‘good’ examples are people who will use the system, simply called ‘user’. We assume that then is the fundamental definition of user.

The user in the other good example is ‘company’. Since the company has no fingers, we assume that the actual user is a company employee, but that the objective is the company’s – the person is the company’s amanuensis, or, prefiguring our later explanation, the instrument of the company’s collective will. We will call the person-or-company entity ‘Party’ hereafter after Fowler.

Cohn says the first example is not a good user story because BigMoneyJobs users would not care which programming language was used. I can’t see how to squeeze a reasonable user at all into the passive ‘the software will be written in C++,’ no matter how acrobatic my grammar skills.

Cohn then tries to clarify. “If this were an application programming interface, then the user of that system (herself a programmer) could very well have written that ‘the software will be written in C++’.”

Ok. If you are making an API, then the developers who are going to be writing against it are the users. That _might_ make sense. (Shouldn’t the user be the system that will be calling the API?) But specifying it be written in C++ just seems out-of-bounds for a user requirement. The interface – CORBA IDL comes to mind as an interface frequently implemented in C++ – yes.

He says the second example is no good because the _real_ users, i.e. we can infer that he means the ‘program’ is not _really_ a user, “do not care about the technical details of how the program connects to the database.”

So he says on the one hand that it is ok to have technical details (‘C++’) in a user story, but on the other hand it’s not (‘database connection pool’).

Why is it ok for one and not the other? He gives us a clue: “Stories should be written so that customers can value them.”

So we assume the programmer user of an API values that it is in C++, but the business user of BigMoneyJobs does not value that its back-end data is accessed via a connection pool. He says that it if that actually _is_ a requirement (thought that is what the user stories were elucidating) that there are ways to express the requirement that are valuable to the business user. Which he leaves us with as the ‘What’s a User Story’ cliffhanger – tune in to Chapter 2 for the exciting conclusion!

Before we get there, though, Cohn goes on to advocate that the customers and users be the primary authors of the user stories. Which means projecting themselves into the ‘user’ slot.  (So _their_ answer to the question ‘What is an agile user’ is easy – ‘I am!”) But that where the users are not available, something called ‘User Role Modeling’ can help.

Cohn then reinforces the tacit fundamental definition: “A user story represents…something a user would be likely to do in a single sitting.”

In expanding on the ‘value to the users’ idea, closing the cliffhanger, Cohn says that stories that are valuable to the actual intended users are ok, and that stories that are valuable to the purchaser are ok (“The dev team will product documentation suitable to an ISO 9001 audit.”), but that stories that are valued only by developers (“all connections to the database are through a connection pool”) are not. He suggests that developer-valued stories can be written to be customer-valued, i.e. instead of speaking of database pooling, we should say something like “Up to 50 users should be able to use the application with a 5-user database license.”

Cohn goes on to talk about how to divide up stories that are too large to do in an iteration. There are two kinds of too-big stories, he says, compound and complex. Compound is a just a bunch o’ separate user stories, which split naturally.

In talking about dealing with complex stories Cohn give an example, splitting ‘A company can pay for a job posting with a credit card’ into ‘investigate credit card processing over the web’ and ‘a user can pay with a credit card.’

Here he has introduced a new kind of story – not one that speaks directly to a user goal at all, but one that describes a ‘spike’ that will prepare the project team for handling a subsequent story. Who is the ‘user’ of the “investigate credit card processing over the web”? It simply doesn’t fit our working definition of user story without stretching it beyond reason.

Surely a user story can’t simply be whatever you’d like.

In Chapter 3, Cohn suggests that it is a fallacy to write stories from the perspective of a single uber-user, that that approach can lead to undiscovered stories, and suggests user roles as the solution.

Using his example project, BigMoneyJobs, he asks – his italics – “when we talk about user stories, who is the user we’re talking about?”

Finally!

But rather than providing intensional rigor, he simply identifies a few possible users of the system, both job seekers and job posters, by name and brief description – sketchy (in the non-teenage-sense) Alan Cooperian personae.

He suggest that “[w]hile each user comes to the software with a different background and different goals [my italics] it is still possible to aggregate individual users and think of them in terms of user roles” – “collections of defining attributes that characterize a population of users and their intended interactions with the system.”

So we are still working in terms of the fundamental definition – humans who will interact with the software/system.

While our system will satisfy its set of high level goals – in his example the primary user goals are Find a Job and Find an Employee – they can be satisfied by a series of sub-goals which may be more or less important to particular segments of the highest level user demographic. And those segments may have other secondary goals in common, after Cooper, “some users favor convenience, others favor a rich experience, and so on.”

Cohn does call out system users in a boxed sidebar:

“As much as you can, stick with user roles that define people, as opposed to other systems. If you think it will help, then identify an occasional non-human user role.”

‘Occasional’ makes it sound as if there is a choice you are making willy-nilly among alternatives. Surely there is some set of ideal user roles for a given system. There must be a way of determining in a given instance what the appropriate users are.

Cohn does draw a perimeter of a kind:

“[w]e don’t need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of our project. Since other systems are rarely purchasers of our system, they can rarely make or break the success of our system. Naturally, there will be exceptions to this, and if you feel that adding a non-human user role helps you think about your system, then add it.”

Really? Write stories for the people writing the checks, and add a system user if it helps you think?

Cohn suggests capturing these user roles on user role cards. He then goes on to suggest that some teams may find value in fleshing out Cooperian personae – detailed vignettes describing individual users based on role characteristics to help bring them to life, and/or Djajadiningrat (great name!) et al’s ‘extreme characters’, a technique where you use fringe user characters, almost caricatures, such as hookers and Popes, to effectively explore the skinny ends of your user demographic space’s bell-shaped curve. But in neither approach are the users usefully compared to Cohn’s base user story users.

We are provided one last chance to find out what bad users might be…Cohn catalogs ‘story smells’ in Chapter 14.

Unfortunately none of them captures the peculiar pong of a ‘bad user.’

He does advocate that we capture non-functional requirements as system user stories (with no user): “[t]he system must support peak usage of up to 50 concurrent users”

Let’s try to synthesize Cohn’s definition of user:

“An agile user story user is a human or company who is paying for a System or a human or company working in a given role who will interact with the System, and who can make or break the System’s success, and occasionally is a System user if it will help the developers think or capture a non-functional requirement.”

So I think we can see that there is a fundamental lack of rigor in the agile methods around the definitions of users and consequently a lack of rigor around what are valid and appropriate user stories.

In his chapter on User Role Modeling Cohn acknowledges a debt not to any of the Agile Manifesters but instead to the usage-driven design theory of Larry Constantine and Lucy Lockwood and the goal-directed design theory of Alan Cooper.

Let’s look at Cohn’s sources and see if we can find more clarity on users there.

Larry Constantine’s most recent concise description of users is in his 2005 article “Users, Roles and Personas.”

Constantine and Lockwood’s highest level methodology structure looks like this:

Role Model -> Task Model -> Content Model -> Visual and Interaction Design

C&L’s original articulation of what are now called ‘task cases’ came about because use cases were seen to have “too many assumptions and premature decisions about the user interface being designed.” He says that task cases have had widespread adoption, and actually cites the Cohn book we have been discussing as an example.

Forgive the extended quote, but after reading dozens of agile parrots’ prose I find Constantine downright lyrical:

“A task case represents a single, discrete intention carried out by a user in some role (my italics.)

“Task cases are also called essential use cases because they are stripped down to the barest essentials of the task. Each task case is expressed as a dialog in which user intentions and system responsibilities are abstract, simplified, and stripped of all assumptions about technology or implementation. This form of description is intended to get closer to the essence of what the task is really about from the perspective of the user in a role and to avoid making unintended or premature assumptions about the form of the user interface to be designed.

“The need to anchor the task model in an appropriate understanding of users quickly became apparent to those working with essential use cases. User roles emerged as an elaboration of the software engineering construct of Actors (Jacobson et al., 1992), which, like use cases, required adaptation to better suit the needs of user interface designers.”

“User roles capture and carry the essential understanding about users.”

“In the broadest sense, a user role has been defined as a collection of characteristic needs, interests, expectations, and behaviors in relation to a particular system (Wirfs-Brock, 1993).

“In its most compact form, the form now most commonly used, a user role is represented by its Context, Characteristics, and Criteria, that is, the context in which it is played, the characteristics of its performance, and the criteria that must be met by the design to support successful performance of the role. Context includes the overall responsibilities of the role and the larger work and environmental context within which it is played. Characteristics refer to typical patterns of interaction, behaviors, and attitudes within the role. Criteria include any special functional facilities needed for effective support of the role along with design objectives of particular importance to that role. Such criteria for effective support of a role are sometimes referred to as usability or user experience attributes.”

Ahhhh….sweet like pure oxygen, isn’ t it?

Larry Constantine is also a lot clearer than Cohn about the prioritization/ranking of user roles.

“In usage-centered design, user roles are usually ranked by anticipated frequency and by business importance. The agile modeling technique for making these rankings is to sort index cards representing the roles into order (Constantine and Lockwood, 2002). On the basis of the combination of these two potentially different views of priority, a small subset of roles is distinguished as “focal” roles. Focal roles serve as a central focus for the rest of the design process, but not to the exclusion of other user roles.”

Unfortunately in Cohn’s popularization this vital closure has been lost – focal roles become the vital ones “who can make or break the success of our project”.

The overall rigor we have been starving for in Cohn is supplied by Constantine:

“The complete task model is expressed by the narrative bodies of all the individual task cases along with a task case map similar to a user role map but showing the interrelationships among task cases. The task case model can be checked against the user role model to verify that all user roles can be fully performed with the identified task cases and that every task case is genuinely needed for the performance of some one or more roles. The objective is to be truly comprehensive, to cover all tasks needed to fully perform all identified roles. In principle it might seem that a complete task model is an unobtainable ideal, but in practice we have found that, with well-timed and thoughtful reviews along the way, it is rare to discover missing task needs late in the game.”

So our fundamental conclusion is this. There was a lack of clarity in the original exposition of agile methodologies around users and user stories. Early practitioners such as Cohn who popularized the user story approach based their work in part on the ‘essential use cases’ or ‘task cases’ in the usage-directed design tenets of Larry Constantine et al. But the potential rigor present in Constantine’s full method was lost in their adaptations. While there is clear value in Cohn and other popularizers’ approaches for greenfield projects, there is insufficient guidance and rigor around the definitions of users and user stories to help agile methodology adopters for non-greenfield projects make good decisions.

Here I would like to draw on the work I’ve done on use case actors. To do that, I need to distinguish use cases from user stories.

But I find this is a very difficult task.  And I am not alone.

Alistair Cockburn, the Eldest Son of Use Cases (if Jacobson the pater familias) has practically thrown up his hands trying.

“I’ve tried answering this question so many times and in so many ways: “What’s the difference between a use case and a user story?

I know what each is, I know how to describe each; I’ve described each and even how to relate the two. I’ve finally concluded that a user story is to a use case as a gazelle is to a gazebo.

See if you can describe the difference without just enumerating what each is.

As the Mad Hatter asked: “Why is a raven like a writing desk?”

And a few dozen subsequent comments on his webpage do nothing to illuminate.

Fellow Manifester Martin Fowler says that

“[Use cases and user stories ] have a complex correlation. Stories are usually more fine-grained because they have to be entirely buildable within an iteration (one or two weeks for XP). A small use case may correspond entirely to a story; however a story might be one or more scenarios in a use case, or one or more steps in a use case. A story may not even show up in a use case narrative, such as adding a new asset depreciation method to a pop up list”

But the most clarity comes, as we might expect, from Larry Constantine:

“A task case represents a single, discrete intention carried out by a user in some role.”

Based on the relationship of task cases to use case, we can infer this:

• A use case represents the collective scenarios to achieving a high-level goal for a system user.
• A user story is one or more task cases that can be solved in a given time box, where each task case represents a single, discrete intention carried out by a use case user in a particular role consistent through the story.
• An intention is an attempt to satisfy a sub-goal, where a series of sub-goals adds up inexorably to an overall user goal as described in a use case.

So a user story user is one of the facets of a use case user…the multiple personalities of all the user story users sum up to the use case users.

So a user story user IS A a use case user – IS A in a generalization-specialization sense.  It is a complex sub-type derived from many partitions on use case user.  The partitions themselves may be categorized as Constantine’s context, characteristics and criteria.

Progress.

As we have demonstrated, a use case actor is a direct or indirect volitional entity.

So a user story user is a role played by a direct or indirect volitional entity with respect to a system.

A user story is an attempt by such an entity in a given role to satisfy an intention, where said intention represents the achievement of a sub-goal participating in the aggregate accomplishment of the goal of the volitional entity.

So whither our Big_New_EDI_System Project?

Cohn’s sample project in ‘Applied’ is a modest web-based job board.

He ends up with 31 use cases. Only three of them are neither ‘a user’, ‘a repeat user’, ‘an administrator’ or ‘a report viewer.’

“The system must support peak usage of up to 50 concurrent users.”

“Orders made from the website have to end up in the same database as orders made by phone”

“The site always tells shoppers what the last 3? items she viewed are and provides links back to them

In Big_New (sounds political like Zbiegniew or Agnew : ) there are 100 user stories. Ninety percent of the users are ‘developers’ or ‘transactions’.

An EDI project will obviously have many fewer direct volitional entity users than a web-based job board.  And it will be much more challenging to define the user roles well.  There will be a lot of system users. That is why we need the definition rigor – it is not a happy-path vanilla-case project for agile.

There might be an objection raised from the touchy-feely user story school that says a user story is just a promise for a conversation to be held later.  So that not much rigor is required, and I should untwist my panties.

My first response is that they should go build a doghouse to hang their crystals in and stay away from my skyscraper project.

Biting that back let me just ask this.  For those 81 user stories with developer users, who are the conversations going to be with?

If you are building a compiler or an IDE you will have developer users to talk to.  Otherwise developer users are just plain wrong.  And the user stories made from them are immediately suspect.

Time to raise the hue and cry.