Why I do not work with requirement specifications anymore (and never want to again).
“I write down exactly what I need. That’s the only way potential service providers can get a precise picture of my requirements and create reliable offers that I can then compare.”
Sounds plausible, right? It is, but unfortunately only for simple requirements.
The difference between simple, complicated and complex projects: Only the simple ones can be fully described.
Imagine that you want to build a garden shed. You know exactly how much space is available for it in your garden and what other requirements you have (material, color, sliding door). You look at suitable models online and finally order one. What are the chances that everything will go smoothly and that the garden shed will end up exactly meeting your previously defined expectations?
Now imagine you want to build a house. You discuss your wishes with the architect, who then draws up a precise list of specifications, which he uses to invite tenders. What do you think the chances are that everything will run smoothly?
Now imagine you are building something great and new, that no one has ever built like this before, e.g. the “Elbphilharmonie” (you can enter the name of practically any individual building project that comes to mind here). You make a very precise plan, you think you have considered everything… But well, unfortunately, it is not so. The Germany among you probably know the outcome of the story about the construction of the “Elbphilharmonie”. ;)
Why is that? Uncertainty in “how?” and “what?” increases complexity exponentially.
The academic Ralph Stacey has studied this scientifically. The higher the uncertainty in the two dimensions “requirements” (What is to be built?) and “implementation” (How can it be achieved?) become, the more difficult it is to work according to a precise plan.
If the requirements are easy to survey (in the case of a garden shed there are few options) and the details of implementation are known (the company has already built hundreds of identical garden sheds), the project is in the “simple” domain. Here you can well work off a full list of requirements according to a precise plan.
In the case of a single-family house, things get a bit more complicated. If you want a fairly common house, which the company has already built several times in the same way (for example, a prefabricated house), it can work smoothly. If you want something more individual or if one of the companies involved has little experience, there will probably be difficulties. Very individual projects are already in the “complex domain”.
The “chaotic” domain occurs in basic research, for example.
What does the construction industry have to do with my software? It’s rarely as simple as it seems.
If you need a standard software, e.g. an online shop or a representative website, you are probably in the simple of the complicated domain. If you are building custom software, then you are pretty much in the complex domain.
How better to invest your time? In a strong product vision and a rough plan.
If you now try to write down your requirements, which are not yet fully known, you have to make many assumptions about what the users might really want later. You invest a lot of time in planning for contingencies that will almost certainly not come about in the same way. While this doesn’t necessarily hurt the project, it’s also not time well spent.
Of course, you still have to think about what exactly you want to achieve. The goal must be clear, but not necessarily the exact path. For this reason, it is better to invest your time in a strong product vision. I described how this can be done in a blog article “How to create a meaningful agile product vision”.
How can you roughly capture your requirements without investing a lot of time in hypothetical plans? With a user story map.
Once you have a well thought-out and coordinated product vision, you should roughly capture the requirements. For this purpose, we recommend the “user story mapping” technique, in which the requirements are determined in the form of user stories along the value chain for the most important users (User Journey). After that, you have a “map” of the project on which the requirements are displayed along the user journey and in ascending priority. Here you can see which requirements should be met first in order to deliver a functioning product to the customer as early as possible.
Caution: You should only define the user stories that you can work on in the next four weeks in the same level of detail in which you would write a requirements specification.
Conclusion: Goodbye specifications, hello User Story Mapping
Only in very simple projects can all requirements be reliably planned. Instead of a comprehensive requirements specification, you should develop a strong product vision and a rough plan in the form of a User Story Map. In the further course of the project, you then always plan the requirements in detail, which you will implement in the next four weeks.
