What is the exact difference between user stories, use cases or requirements? They all have the same goal: capture the needs of the business so they can be translated into a working software application. But there are differences in how the same goal is achieved.
Requirements tend to be very formal, text-driven and structured (using categories, sub requirements f.i.). They have to be unambiguous, 100% correct and complete. They also should be measurable and testable in the way that you should be able to verify how far the delivered software fulfills the requirements.
Use cases are also formal, text-driven, structured, complete and 100% correct. Use case diagrams deliver additional information on the roles that interact with the use cases and the system boundaries. Use cases are user oriented. They describe the interaction of the user and the system. Although I never really grasped the enormous use of use case diagram, that are very static and mainly focus on relationships between users and use cases and include, extend or generalization patterns.
User stories however focus on the value they have for the user. They are less formal and are intended on stimulating open conversations: as a <user> I want <something> so that <benefit,value>). Conversations should be conducted between all participants in the project, not only between business and product owner/analyst as in traditional projects. Also allow them to continue during the whole life-cycle of the project. Completeness is not that important from the beginning: you do not need to specify all details upfront. You do what needs to be done at the right moment, just-in-time. In the end you might end up with a fully documented user story but the actual process of holding conversations with everybody at any time during the project life-cycle is key. Some agile teams do not write out all details. However, keep in mind that there isn’t yet a device available for capturing these details from the product owner’s head into a readable format.
Both requirements and use cases are often used in fixed price project where all the needs of the business are captured in a pile of documents upfront. This pile forms the basis for the negotiation between the business and IT (internal department or external supplier), so of course it has to be complete and correct. But you cannot expect from business or IT to know all the questions & answers upfront: new questions arise and answers change during the project. If however, you take this upfront approach, you end up developing all features, whether they are still needed or not, or are not accurate anymore. Or you end up with endless and frustrating discussions between business and IT. Or even with an application that is not being used by the business, or for the worse you will meet in court.
Agile methodologies embrace the principle of change. They accept that gradual insight is the driving factor, not only in software development. So agile adopters start developing the “must have” features (MVP, the Most Viable Product), show them to the business them and let the business test as soon as possible. The feedback from these business tests than drives the next iteration: some features will get a higher priority, other are not that critical anymore and even features are changed. Agile focuses on a product that will be used by the business since they are now in the driving seat.
Trust and responsibility
In order to do so, you have to build trust between business and IT. This asks for a major shift in the way you approach your project. It might seem sometimes scary for the business letting the development team estimate all user stories. Or for IT to allow the business to change priorities and even their needs, even when developing. But only then you will get buy-in from the whole team and you will get the product you really need. Since after all it is you, the business, that decides whether this user story has enough business value for you to be developed in the next iteration.
An agile approach wants to avoid differences in expectations between all parties. All have to take up their responsibility and report any uncertainty about the user stories as soon as possible, not after the code has been written.
User stories are not agile by definition, it is more the willingness to build up a relationship between IT and business based on trust and openness, where all parties take their responsibilities. Doing so will make everybody happier and in the end we can deliver and use a product we are all proud of.