Elephants are not giraffes, and user stories are not requirements. They have common features and a common context, but this does not equate them. However, many people believe that user stories are a kind of new reading of what is traditionally called software requirements - after all, there must be requirements on a project, right? So, I will answer - no, and again no . Firstly, these are not requirements, and secondly, requirements are not what we really need. User stories are, first of all, a chance to see different implementation options, so that later you can take advantage of the opportunities that have opened up. And the requirements ... it is to solve everything in advance, so that later you get bogged down in it.
Is there any point in writing such an article? Doesn't the above seem obvious? No, I believe that the frequent statements like “requirements in the backlog” signal that the paradigm of thinking remains the same, just the signs have changed. The requirements document began to be called the backlog, the requirements themselves - user stories, and now we are "agile" ...
Another sign of possible misunderstanding is the widespread practice of storing user stories in the database with the assignment of a unique ID. It is possible that this is done just for the sake of convenience, but it is possible that this is the result of a persistent tendency to think in terms of requirements.
But the practice of including user stories in a contract is already a 100% sign that user stories are being considered as requirements. The problem here is that a user story, by definition, cannot be as unambiguous as a requirement, and this devalues the contract. Of course, requirements can sometimes also be interpreted fairly freely, but the very technique of writing them initially implies the elimination of ambiguity, which cannot be said about user stories. In addition, requirements are resilient to change as they are included in project contracts. In order to change or add new requirements, they must be passed through the CCB . In other words, stakeholders must first agree and approve. See below for more details on contracts.
So what are user stories? Consider them as a planning tool. With the help of user stories, we prioritize, evaluate and decide in which sprint the corresponding functionality will be implemented. These are all typical features of a planning tool, so don't try to transform them into something else.
The power of user stories is that they give rise to dialogue. Instead of just taking and passing on to colleagues a specification, which is interpreted first by the developers, then by the testers, we start a discussion. We include employees with different skills in communication. And so - for each new feature.
Since the user story, as such, does not carry much meaning, we can simply discard it after the implementation of the corresponding functionality. If you wish, you can carefully keep statistics on the number of stories sold, but this is quite possible and limited.
It turns out that we don't need requirements? In fact this is not true. After all, one way or another there are limitations. For example, medical equipment must comply with FDA regulations . So let's call them constraints then!
And yet, the requirements describe the System in detail, perhaps there is some value for us in such a description? For example, how can we determine whether some behavior of the system is a bug or not, if we do not have formal requirements presented in one form or another? The technique "Specification by Example" will help us here. So it was decided that some functionality should be implemented. You write business rules and a series of examples in such a way that it is: a) easy to read; b) realizable. From this description it should be clear what the System should do. And also, if something goes wrong as a result of changes - the violation of which business rule was the cause of this dysfunction.
As I wrote earlier, the description of the bug should be simple and clear. Bugs are information-destroying things, and they are bad regardless of whether we have a requirement description that covers a given case or not.
Contract
(by Matthias Skarin)
So what are we going to use instead of the requirements specification? After all, we need to understand whether we have implemented exactly what was needed? We will be using agile contracts. Agile - contracts are an opportunity to see the forest for the trees, they allow you to focus on the essence of the project and joint achievement of the goal, the implementation of which will satisfy the needs of users.
Keep in mind, when you think about the contract during the project in order to check if your partner has violated anything, this already means that something is going wrong. The contract should build trust between the parties so that it becomes possible to go beyond the particulars, and not get bogged down in them.
Summary
- Despite the fact that both the elephant and the giraffe have four legs, they are different animals.
- User stories are not requirements, but a planning tool.
- The closest thing to the requirements is Specification by Example.