Nearly fifteen years have passed since the Agile Manifesto was first published, and what started as revolution in software development has grown into a popular movement. Most companies now use Agile principles in some form or another to guide their software development processes.
Software developers have plenty of good reasons to love Agile. Continuous delivery and better communication help business stakeholders stay involved, reducing re-work and preventing scope creep, so that customers ultimately enjoy a more reliable product. Everyone’s happy.
But the transition to Agile development hasn’t been completely smooth. The methodology also brought with it some thorny questions for developers. Chief among these is whether user stories should replace requirements as the guideposts for a development project.
User stories have a clear utility and an intrinsic appeal. Developers who’ve worked on small Agile projects appreciate the simple graspability of a notecard-sized directive. Spread them on the table or pin them to the wall, they’re an easy way for team members to get on the same page. From that position, discussions are more effective and solutions can be found more easily.
In short, user stories are a great way to describe the desired outcomes. They’re good for the “what”: what we’re building, what it looks like. But what they’re not so good for is the “why.”
Large-scale software development projects have always struggled to succeed, often because the final product is cluttered with too many extra features (i.e. scope creep) or it simply isn’t what users need or want. Because failure is so commonplace, developers recognize the need for tools to keep the project oriented, so it stays on target and reaches its destination on time.
User stories on their own are like signs without a map. Developers can use them to keep the various moving parts pointed in the right direction, but they still need to see the big picture. For example, they need to keep the business objectives in sight, not just the specific software functions.
There are three main reasons why developers need more than user stories to achieve the best results.
- Context: Relying exclusively on user stories can easily lead to a bad case of “missing the forest for the trees.” User stories show the parts of the project, but without a deeper structure that connects them to the overarching business goals, they miss the whole.
- Collaboration: User stories are best used when team members are co-located, which was an early principle of Agile development. But when big software projects are spread out across different offices in different places, developers need a better way to support problem-solving discussions.
- Elaboration: User stories traditionally rely on text, which is a very limited way of exploring ideas. Dynamic collaboration relies on other forms of communication, including pictures, models and diagrams to get the point across.
User stories are an effective tool, but they’re just one of many in the toolbox. Developers need systems that promote collaboration while at the same time preserving clarity and providing orientation. That can only be achieved with a centralized hub where team members can easily see both the small details and the grand scheme at once.