When a team work on analysis and software development in parallel, this creates an opportunity to work with requirements in a different way. Specifically, we can consider other communication channels - we can open up dialog. Agile teams primary means of communicating requirements is conversation. The medium of conversation creates the possibility for information flow between all parties. The problems imposed by communicating via documents drop away.
When agile teams plan development, this done by the whole team in a workshop. If you listen in, you will hear conversation flowing around the group. The whole team are partners in this conversation. They discuss scenarios and development options to explore the requirements before development is planned. The beauty of exploring requirements through team conversation is that we develop a shared understanding and have the opportunity to offer our own ideas. Having a two-way conversation between business and IT and flushing out misinterpretation early may prevent developing code that has to be thrown away.
The difference is made clear in Extreme Programming (XP) . The use of Stories is a primary practice of XP. An XP story describes a candidate system feature in language that is meaningful to both customer and developer. Stories have three essential parts: Card, Conversation and Confirmation . Stories must be small enough to implement in a single development cycle (XP teams use a one-week cycle).. To support collaborative working, stories are written on index cards. Index cards provide a low ceremony way to document development plans. Each story card represents a conversation that has taken place. Automated tests are defined for each story, which are used to confirm that the system supports that story.
Other agile methods do not explicitly use stories but also emphasis that requirements descriptions need to be short and loose, the bare-minimum needed to plan development. Typically, requirements are listed as one line description maintained in a backlog in priority order. Features may be swapped in and out of this backlog and it is assumed details about each requirements will be determined as part of each development cycle.
Requirements specification documents are usually expressed in impersonal and cold language giving us "whats" without business motivation. This is quite different from the way we tell stories. Using story form we start by describing the context and give background to the players in the story. A story takes the players through a chain of events that communicates a desired outcome. A story breathes life into a limp requirement. Through the story, the listener grows to understand the pain experienced by the users and the burning need for the software – this can have a profound effect on motivation within the software development team. By discussing explicit situations and our reactions to them (via the system under construction) we can achieve a shared understanding. Understanding the big picture can help programmers to develop software solutions that are a better fit.