I’ve been working for many years in the requirement management field and I have realized that even experienced analysts or system engineers are often not used to work with requirements properly.
The first hard concept to understand is that a requirement is expression of a need, not a specification to implement. That looks straightforward and totally sensible, but still happens to be pretty hard to apply.
A requirement is therefore an item in the space of problems: it is a problem to solve, not a function to deliver. On the other hand developing SW is just about solving problems, not writing code, right?
For instance, is it “I want a bridge”, a requirement? Is that a problem to solve or a solution?
What might be the real need behind? Maybe: crossing a river without getting wet.
As you can guess, explicating the real need opens up more options to find a proper solution. One solution is definitely the bridge, other solutions could be a boat or a raft or even swimming. And you don’t even need to build anything in the latter case.
This is a very important job: understanding the real need behind a customer request.
That’s why we don’t say writing requirements or defining requirements, but eliciting requirements, because it is about digging out real problems and helping the customer understanding her real need (or at least making a hypothesis on the real need which must be validated through a fast feedback loop).
Then the Product Owner uses her brain, skills, domain knowledge and the brains in her team to translate the need in business solutions, in forms of User Stories, which is the language the PO speaks with her team.
Requirements are instead the language the Product Owner speaks with customers, but it would be too easy and not profitable downloading the requests on the team as they are. Challenging customer needs is a very crucial activity to find a solution compatible with business and maximize the Return on Investment.
I repeat many times to the POs I coach: your job is not to push your team to do as much as possible – your job is to challenge requirements, so that your team can do as little as possible.
Cutting some scope because it is not needed has an effect that no efficiency program whatsoever can ever beat: effectiveness eats efficiency at breakfast every morning.
Focus on the worth solving problems: If you get good at delivering shit fast, you just get a lot of shit (Jeff Patton).
BTW, engineers are paid to solve problems, not on how much they build. Instead the more code you produce, the more technical debt you normally accumulate, which on its turn will reduce your long term Return on Investment.
Buddhist masters know that, if you spend enough time in finding and formulating the proper question, the question itself will contain the answer. Unfortunately I saw too many times the pattern of jumping directly into solution mode as soon as a request arrives and masking business solutions as requirements.
This article is based on a post I wrote some time ago on my blog (R)Evolutionary Agility. You might find other topics of your interest at: http://evolutionaryagility.blogspot.com/. Feel free to leave your comments as well.