Words shape thoughts. The word “requirements” has limited software professionals to a very narrow set of information about the value they produce. In the end, we’re supposed to be delivering software value, which is a much broader, more ongoing conversation than the content you create just before working on the code.
While a switch to user stories helps start this transition away from traditional requirements, that’s only a step. How do we understand what capabilities will help the customer? Do we understand the customer at all? What hypotheses are we posing about the value of adopted software? How do we test these hypotheses, so we can make adjustments, if the software isn’t providing perceived value, or people aren’t adopting it (two sides of the same proverbial coin)? “Requirements” provide a very small view of this very large canvas of software value.
So, instead of sticking with “requirements”, a word with some baggage, teams are already talking about customer insights, which take a variety of forms. Personas, user stories, story maps, wireframes — these and other types of content fit into the toolkit that team will use to guide their efforts to delivering software value.
[Editor’s Note: This post is part of the annual “Cutter Predicts …” series.]