User Stories Don’t Work for Our Team
User Stories Don’t Work for Our Team
The 'rules' related to user stories are more like guidelines. Your system doesn't have to be a customer-facing, full-stack app to leverage user stories effectively.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
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 vwhen 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 backend 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.
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 backend 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!
Published at DZone with permission of Dave Nicolette . See the original article here.
Opinions expressed by DZone contributors are their own.