Writing the Requirements in Agile or Waterfall (Prince2), whats the difference?

Projects are carried out to meet the needs and requirements of the customer, and the executive. In short the requirements. These are elaborated in the 'work items' for the project, for example, user stories, 'smart use cases' or features. These work items then form the “backlog” of the project.

Just as in traditional projects (prince2) completed the requirements for agile projects, a number of stages (in which different activities) are carried out to attain the requirements. In both types of projects (agile and waterfall) there will be the stages of analysis, design, construction, testing and acceptance of the requirements. The major difference between traditional waterfall and agile is therefore not elaborated how the requirements are made, but the moment at wich they are developed. I compare the effectiveness of both hereinafter on the basis of a simple calculation example.

Traditional requirements:
A traditional project starts with the further development of the requirements until they are fully and completely understood and then written down. Complete means that all requirements have been totally developed. Complete means that all of the necessary details already have been described up front. This happens traditional (waterfall) and will be done to get ‘solid’ feeling of security to estimate the budget.

Based on the given requirements an estimate of the expected costs and duration of the project can be taken. This then results in the project plan. This traditional method means that at a earliest stage much time is spent in the project on developing the requirements. Assume for simplicity that there are one hundred requirements in any given project, and that it is necessary for it to work out in minute great detail twenty-hour per requirement (team of 8 people working 2.5 hours each on 1 requirement = 20 hours). In total, the team in waterfall now burned already two thousand hours of the requirements up front.
While many organizations assume that this is an efficient method which eliminates many uncertainties in advance of the project...., the opposite is true.

After all:
? Knowledge. To attain requirements so early and so large in detail degree takes much knowledge and time. Often this knowledge is not yet sufficiently developed so early in the project. Therefore its smarter to work out the requirements at a later time than it is now developed in a waterfall project.
? Brightness. Many of the requirements are so early developed and yet still far away from a clear view of the project. Even it seems on paper all bright and shining. The customer and executive can’t deliver (in the earliest stage of the project) the exact necessary details in detail.
? Change. As everyone knows, the requirements always change during a project. Regardless of waterfall or agile. This is inevitable. Fact of life. There are also always new requirements introduced. Beside all that, insights into existing requirements also change. And occasionally even dilapidated requirements. Research shows that the requirements normally change on average 20 to 25 percent. When this happens, it means in my example that has been 20 to 25 percent of the two-thousand hours; are made for nothing. That is quite something. Four to five hundred hours delivering requirements you actually don’t need. (in my example).

So, to develop the requirements so early in a project at a high degree of detail is not so effective. Moreover: ask yourself, is this high level of detail necessary at this stage of the project right now?

Agile requirements
Agile projects handle requirements differently. Much of the work on getting the details of the requirements will be done just before they are needed. Not earlier.
That's on two occasions:
? At the Estimations. At the start of the project, we determine the rough size of the requirements so that an estimate (poker game) can be delivered. It is sufficient to identify these requirements roughly. However, the business must accept if there is more or less extra work to be done on the requirements before actually building the software.
? At the Realisation. Only when the requirements as ‘work items’ are realized during an iteration (sprint), the total details are really necessary. Now it's time to work out the requirements and work items with the agile team. Just in time. With all the right new insights that are gained in earlier stages.
This offers a very different starting point for dealing with requirements. This principle is expressed in the YAGNI acronym. You Aren’t Gonna Need It. Briefly, this acronym means: all the work that is currently not necessary, should not be carried out until its needed. Agile projects do all the detail work of requirements only when this is really necessary explicitly to get the building of the software started.

For the requirements of my sample project, this means the following. This will require much fewer details at the start of a project than in a traditional project. Instead of the twenty hours a complete detailed requirement up front, it takes this in an agile project perhaps four hours. Only when a requirement as a work item on the backlog has been selected by the scrum team, then it will be worked out in sufficient detail to achieve this task by the scrum team.

This has remarkable advantages:
? New insights. All the new insights to the point of working out details are already incorporated automatically. There are no change request forms needed to capture this last insight and yet to be realized once after completion of the project.
? Knowledge. As a project progresses, both customer, client, as a team gain much new knowledge.
? About the domain. New insights are gained on the techniques used. About the technology. This knowledge allows the development of the requirements later in the project will take much less time. Indeed, there is less to find out. That means for developing in all details the requirements need much less time. Perhaps maybe only eight-hour of working on the requirement during the first stage of the sprint.
? Security. Finally, it is certain that when a requirement is realized it is selected in an iteration and will be made for sure. Again save agile projects this time compared to traditional projects. After all, in traditional projects, there are always requirements that are never realized because they were not needed. In agile projects, only those requirements will get expensive detail attention who are actually realized.

Conclusion.
In traditional and agile frameworks the same basic work is done to get the requirements. Only the moment the details are needed varies enormously. And with that the degree of effort in total. In my sample calculation saves agile project already eight hours per requirement.

Of course, this example is imaginary. But certainly not inconceivable. A little side note. Unfortunately, YAGNI is also used as an excuse not to do the work of making requirements at all. Also not do the proper documentation. Or not to think about the architecture. Not to train the end-users properly. Not to plan the needed data migration. YAGNI does not imply that all this work should not be done but recommends applying for this work only just before when the result is really needed.