As the agile approach to software development has gained in popularity, the construct of the “User Story” has also been broadly adopted. While people might have looked at you funny ten years ago if you told them you were “working on a user story,” today most of the popular software project management tools have “story” as a first-class entity.
With that uptick in usage, however, has come the inevitable dilution of the original concept. Many people today think of “user stories” as just a special template for writing requirements. They are familiar with the “As a … I can … so that …” structure popularized by Mike Cohn, and believe that any sentence written in that format constitutes a user story. Others use the terms “stories” and “requirements” almost interchangeably.
Thinking of stories merely as requirements written from the User’s point of view, however, misses both the point and the power of the story concept. User stories were intended not as a new format for documenting requirements, but rather as a different way of thinking about the requirements process altogether.
User stories are were invented to solve a common requirements dilemma. We need to do up-front requirements and analysis in order to know what we are proposing to build, and in order to decide whether or not to invest time and money in building it. Once we start building a piece of software, however, our understanding of what we ought to build and how we ought to build it almost always evolves, which can render much of previous requirements work obsolete. The agile methodologies teach us to “embrace change” as a normal, expected part of the software development process. But in embracing that change, we find that we are changing our minds frequently about the true “requirements” of the system
Hence the dilemma: We can’t avoid some amount of up-front requirements work, but we want to avoid doing requirements work that will just turn into waste.
This is precisely the problem that user stories were designed to solve. As espoused by Kent Beck in Extreme Programming Explained, the use of user stories allows us to defer most of the complexity of the requirements work until we are sure that we will need it (i.e., right before we’re about to build something). User stories give us just enough substance to do reasonable estimating, planning, and prioritizing at each stage of the process, without the need to delve into details that are likely to change. They also prevent us from talking too much about things that we will never actually end up building.
At least that’s how stories were intended to be used—as a lightweight mechanism for discussing what we might build. With such a mechanism, we are in a better position to explore options cheaply, and to change our minds in response to learning. This is the true power of the user story construct.
With this understanding, it’s easy to see why each user story must represent a small, working, independent, and testable piece of software. Stories need to give us options. If a “story” doesn’t represent something that a customer can choose or not choose to do, then it’s really not a user story.
It’s also easier to see why we need to avoid anything that makes stories “heavier” than they need to be. Creating a new story, changing/adding to an existing story, or deleting a story all should all be low overhead tasks—as easy as writing with a pen on an index card. Once we let it become difficult or costly to change anything in our list of future user stories, then we start to suffer from the same problems that we have with a traditional requirements approach. We try to “lock down” stories earlier, and “get them right” sooner than we really need to.
Mary Poppendieck is fond of saying, “If you have a lot of requirements churn, you are specifying too early.” That is very typical on a software project. Some smart people sit down and do a lot of work to figure out what should be built, only to discover months (or years) down the road that much of that work is not usable by the development team because of changed priorities, changed environments, or an ever-evolving understanding of what software will best solve the original problem.
The best way I know to avoid this problem is User Stories. Don’t settle for requirements masquerading as stories. Instead, use stories to help you do the requirements work in an ongoing, iterative, and just-in-time fashion.
Pingback: Maria Smith()