User Stories Don’t Work for our Team

Here’s one I hear all too often (paraphrased):

“Our team doesn’t support customer-facing application software. We support a set of internally-consumed APIs for our SOA environment. Therefore, we can’t use User Stories.

The User Story is one way of describing a piece of work to be done. The canonical form “As a something I want something so that something” is only an example to help people get started, when they aren’t sure how to write User Stories. It isn’t a “rule.”

One hopes people don’t remain at a beginner level forever, and they get comfortable with the idea of lightweight requirements pretty quickly. Then they won’t need a template like that anymore. One hopes.

That API team I mentioned could regard client applications as their “users.” That would be fine. The Gods of User Stories won’t be angered. (I’ve met some of those gods. They’re pretty mellow, as gods go.)

Oh, but you’re wrong, Dave! User Stories have to specify the business value of the story. Otherwise, they’re not proper User Stories.

Okay. Let’s think about that. A single piece of work may or may not provide 100% of “business value” for a discrete customer. A single piece of work may provide partial support for many forms of value for many customers. This is often the case when the software being modified is several layers of abstraction away from customers…like an internally-consumed API, or a legacy back-end application. It may be hard to quantify the specific business value provided by a particular modification, but we can still use User Stories to plan and track the work, if we choose.

Wrong again, Dave! The “rule” for agile development is that we form cross-functional teams of full-stack developers so that no one is working on little bits and pieces of code that only provide value when they’re all assembled. The User Stories represent vertical slices of functionality, and each one provides 100% of a defined piece of “value” for a discrete class of customers. Otherwise, you’re doing it wrong!

Sure, you’re right, in principle. And you’re right in practice, too, provided we’re talking about a relatively small organization (or a federated organization) that works with relatively up-to-date technologies.

When people talk about “full stack developers” they usually mean mobile/web to web server to a lightweight database (either NoSQL or relational wrapped in an ORM), and maybe an app server. It’s certainly feasible to form cross-functional teams that include all relevant skills and are small enough to operate smoothly. It’s easily within the scope of one brain to learn CSS, HTML, JavaScript, Ruby|Python|PHP|Java|C#, a build tool, a CI server, a data abstraction library like JPA or ActiveRecord, and a couple of frameworks.

But many thousands of developers work in larger organizations, where the “stack” is too deep for any one individual to claim “full stack” expertise. A cross-functional team that covers all the bases from mobile to assorted legacy back-end platforms plus a whole zoo of third-party packages, and all the plumbing in between, would be too large to function smoothly. In that sort of environment, there are definitely teams that support bits and pieces of any given vertical slice of functionality. Being right in principle doesn’t help much in that situation. Sometimes we have to take reality into account, notwithstanding the ideal case.

Three things to remember about User Stories:

• They’re meant to be a placeholder for a conversation, not a full-blown detailed specification. The User Stories are not the product you’re delivering, so don’t obsess trying to perfect them. Keep them light. Include references to supplementary documentation, if that helps clarify the intent.
• Any format will do, provided the story answers (a) who wants it? (b) what good is it? (c) what do we have to do (but spare me the details)? and (d) how can we tell when it’s done? (As a practitioner, I’ll suggest the most important question is “how can we tell when it’s done?” It’s the one that will bite you if it’s not answered. It’s also the one that’s omitted from the “As a” formula. Just sayin’.)
• There’s no need for all teams in an organization to write User Stories the same way. Different teams do different work, after all. Resist the bureaucrats!