Developers who use Agile methodologies understand that software projects evolve over time. Plans change as team members develop a better understanding of how the product will work, and since that understanding is mainly achieved through the process of coding and creating, the project needs to be flexible enough to accommodate changes as they come.
This is especially true at larger companies, where teams are spread between offices and across continents. Digital strategist Paul Boag observes that when more players are involved, “the digital roadmap is in a constant state of flux, with new priorities constantly jumping to the front of the queue.”
To combat the confusion that can be created by sprawling, large-scale projects, Agile developers do everything in their power to cultivate collaboration on their teams. One of their most dependable tools is the user story: simple summaries of the functional elements of a software project that act as bookmarks for discussion.
As we’ve already discussed, user stories are helpful but limited. They only offer an outline of the customer need, not the details, because that’s all they are meant to do.
In their introduction to user stories for the Scrum Alliance, William Nazzaro and Charles Suscheck write, “Remember that the purpose of a user story is to encourage collaboration. A user story is a promise to have a future conversation; it is not meant to document every aspect of the work, as you might in a series of traditional requirements statements.”
Traditionally, user stories are written on notecards, dubbed “story cards.” Story cards only work properly when they’re concise. If they contain too much information, they’re no longer useful for collaboration. Agile coach Jim Shore confirmed this point eloquently when he wrote about a phenomenon that he called “story card hell”:
“Story card hell is when you have 300 story cards and you have to keep track of them all. This doesn’t work. Story cards aren’t meant to capture all of the details of your product requirements. They’re only supposed to be a sentence or two. At most, a paragraph. When you have 300 cards, you lose the ability to understand what they mean.”
While developers and Scrum teams will sometimes find it useful to sketch their user stories on notecards, story cards clearly can’t support the entire burden of collaboration that’s required for a successful project. There are too many other tools that developers can use to support collaboration—from user profiles and other types of user research to good old requirements and objectives—rather than rely on one very limited device. User stories play an important role, but only within a broader collaborative framework.
The business writer Michael Labeouf once observed that “A satisfied customer is the best strategy of all.” On the surface, user stories are expressly designed with the customer in mind. But if good collaboration leads to efficient design and more reliable products, then developers need to give team members a simple way to include all the available resources in their conversations, not just story cards.
Traditionally, user stories supported face-to-face conversation between Scrum team members on smaller projects. But as Agile becomes prevalent at larger companies where co-location isn’t a reality, user stories have evolved to be part of a layered digital exchange, where high-level and low-level descriptions can be coordinated together.
User stories are a critical tool that developers need to support collaboration, but they belong on a continuum of information interchange that includes much else that wouldn’t fit on a story card. Developers need tools that further the whole conversation, not just part of it.
If you are interested in learning how Blueprint can help you with your user stories, please contact us today.
