User stories are a bit of semi-refined raw material that systems are created from. They're a way to represent users' needs. Most importantly, they communicate an understanding of users' context to the people who are building the software. User stories help to make it more difficult for software development teams to succumb to the ever-present threat of losing track of the user's bigger picture.
Aside from raw human ideas that user stories represent, they are the most flexible artifact in software development. Then can be created at any time. They can be changed at will. They can be combined. They can be subdivided. They're not intended to become fixed, and anything that serves to make them fixed is a disservice to the value they offer. User stories aren't fixed in a point in time, just as needs aren't fixed. They change because conditions change. They change because our own understandings change and improve as we gain the clarity that comes from working with user stories, and from building the products that satisfy needs.
When we realize new clarity, our responsibility is to reflect that new clarity in the form of new stories, or new subdivisions of existing user stories, or through the combination of existing user stories, and even from the removal of user stories from the product definition entirely.
The user stories that describe our needs tomorrow are going to be different from today's. Knowing this as we do, we have we gone from recognizing the transient, temporary nature of user stories to the point where we now tend to capture them in tools that make them harder and to change, and harder to take in at a glance and to glean new clarity from. When we do this, we're increasingly unlikely to update user stories to reflect the improved understand we cultivate as we work with them, with users, and with the software that we're developing.
The more that we calcify user stories in ever more concrete media, the less we make necessary course corrections along the way. There is little that so obviously contradicts "Agile" more than inviting anything that adds to the calcification of requirements. A principle duty of user story management in Agile development is to protect them from becoming encumbered by the notions of permanence that obstructed software development methodologies that predate the effectiveness of Agile methods.
We pat ourselves on the back for having evolved beyond the quintessentially-primitive "300-page requirements document", but often all we're doing is bringing some of the same old problems forward to our "new" requirements formats. Sure, we've outgrown the massive, big-batch requirements doc, but the genetic material of the disease that infected those documents have evolved into a newer problem for newer artifacts, and ultimately, the problem is still the same essential problem. We're so pleased with ourselves for our new Agile ways that we fail to see that we're repeating the same mistakes, except with new material.
Here are some things to keep in mind that can help with the relapse into the same old mistakes:
1. When you forget why you're doing something the way you do, the answer isn't in a user story archive. The answer is in revisiting what you're doing to make sure that it still holds true. Do this with interactions and with people. Use tools and processes to support the human interactions.
2. User stories are not artifacts for regulatory compliance. User stories are a scratch pad of human understanding at the present moment. They are chuck for the software development grinder. What comes out the other end should be the software that itself explains why things are as they are. If you need a permanent record for the purposes of regulatory compliance, go ahead and create one. Nothing in Agile stops you from doing that. Just don't hang a stasis anchor around the neck of user stories. If you do, you'll strip them of the benefit that they bring to software delivery.
3. Have one master copy of a user story while that user story is in-progress. The master copy should be the one that is most immediately accessible to the most people who are involved in turning ideas into software products. They should be be posted using the most visible medium possible - one that requires the least amount of human interaction to casually-scan a project's gallery of user stories.
4. Throw user stories away once you deliver the working software that addresses the needs expressed by user stories. The software and its supports are enough to describe why it is the way it is. If you no longer remember, and if the software and its supports and the mechanisms and practices of institutional memory aren't sufficiently self-descriptive, revisit all of these issues as an opportunity to improve the production system in a way that doesn't invite more tool-centric bureaucracy.
Here's a bit of a side note to consider: The principle sponsors of the Agile 2010 conference are both "Agile" tool vendors.
If one of Agile development's primary tenants is to value people and interactions over processes and tools, how is it that the only Agile organizations producing enough disposable income to support Agile development itself are tool and process companies specializing in Agile requirements management and requirements compliance? Somehow, we've walked in a circle - yet again. And one of the things we've left on the trail behind us is the understanding of how things went wrong last time, as well as our commitment to avoid expediencies that don't serve sustainability.
The process methodologies that predate Agile are often roundly dismissed by agilists. But there wasn't really inherently wrong with them. Things back then started getting silly when tools started getting silly; when we began to defer to tools as authorities rather than to the people needing and the people solving needs.
One of the first definitive steps into the downward spiral of mindless process bureaucracy hell is the calcification of requirements. And no matter how temping it is to succumb to the materialism of hardened collections of user stories, we don't get to hell without passing through those gates.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
