The Bad-Requirements Mea Culpa

I often take part in conversations on the topic of “bad requirements”. Typically a project manager starts complaining about how poorly one feature was developed. Maybe the feature went out very late, or it might be because of an abnormally big amount of bugs, or whatever problem that you can imagine (or remember of). Sooner or later in this conversation, the PM starts thinking that something went wrong because of him. And inevitably he ends up blaming his requirements.

It is very easy to blame the requirements; and the more precise they are, the easier it is to find that they are bad. I remember of a particular story of a website that should have been released in three languages, but the Spanish contents were not ready yet. It was decided to open the site in French and English only. Instead of explaining the problem when describing was needed, the PM in charge wrote something like “Hide the Spanish flag”. Very precise, and very incomplete. The developer did not ask any questions and actually hid the flag using CSS. The Spanish site was still reachable and got on top of Google searches with Lorem Ipsum contents.

Nevertheless we should not blame the requirements. If you recognize yourself here I’ve got a good news for you : there ain’t no bad requirements. 

Conversations

In the Agile world, the word “requirements” has been considered harmful and is now viewed as a monster that should be avoided at any cost. I profoundly disagree with that because, once again, “requirements” is just a word. The truth is even Agile practitioners use requirements, and this is because we need a way to express what we need to do with the product. Sorry my fellow agilists, but the truth is that user stories are functional, user-centric, goal-driven requirements.

Requirements, whatever the form you use, are not bad in essence. They are just tools. Like any other tools they can be used correctly or badly. But on the contrary to other tools that can be hard to master and very error-prone, requirements are quite easy to use if you remember what their real purpose should be. If you write requirements in stone and never talk about them whatsoever, you are running into big troubles. But whatever how you write them, if you use requirements as a conversation igniter, then you’re good.

Let’s go back to the example above about the Spanish web site. The real problem is not that the requirements were to hide the flag. No. The problem here was that the PM did not explain the purpose of what he needed, and that the developer did not ask. So the real problem is the lack of a good conversation, as simple as :

– Why do you want the flag out ?
– Well, the Spanish contents are not ready yet. We don’t want the Spanish site to be visible.
– Hum… Okay, maybe we should make sure the site not reachable at all, and set up a redirection just in case we forget something.

Tada! You’re done. No user story, no weird template or framework whatsoever, but only one thing : a conversation. A requirement is a tool which purpose should be to enable a conversation so that the best possible options are chosen, but there is no bad requirements, only bad conversations.