A case of trust, responsibility and collaboration?
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 achieving the same
goal.
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.
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/role> I want <something>
so that <benefit,value>
Conversations
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.
Upfront
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 in court.Gradual Insight
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
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 a software 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 software application 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.Responsibility
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.
Conclusion
User stories are not agile by definition, it is more the willingness to building 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 an application we are all proud of. And it is also more fun.
