Words have power, and the wrong word can steer your whole project wrong.
Requirement: something essential to the existence or occurrence of something else.
Few words have done more harm to our industry than this single word “requirement.” The very word invokes an aura of non-negotiation and permanence.
We all know it’s impossible to gather all the requirements before the start of a project.
We all know they are going to change.
And we all know there are always going to be more things to do than time and money allow.
So why do we insist on calling them requirements? And if they are not “requirements,” what are they?
Let’s take a closer look at what a software requirement really is, and how it maps into our world of delivery.
Throwing in the Kitchen Sink
At XP2002, Jim Johnson, the chairman of the Standish group, shared a study that showed what percentage of features companies typically used on software they had built.
While surprising to some, the study confirmed what many had long suspected: companies regularly build features that their customers seldom or never use, and most of the value of the software comes from a really small subset of features.
So why would companies do this? Nobody sets out build a product with dozens of features their customers will seldom or never use. So why do intelligent people do this?
Mostly it has to do with how our industry has historically trained customers to communicate what they need to get out of their software.
“Hi, customer. Can you write down everything you could possibly need in your software? We ask you to do this because once we start delivering, we are going to be on a tight budget and schedule. Oh, and if changes do come up, please forward your requests to the change control board. They would be happy to assist you in handling any changes you’d like to see made to your software.”
This is what we used to tell our customers. If you were a customer, and you knew that a gang of thugs was going to charge you an arm and a leg every time you wanted to make a change to the requirements, what would you do?
You’d throw in the kitchen sink! Because you’d know that this is your one chance to get everything in there.
With so much focus on schedule and money, it’s ironic that most companies don’t realize they could save 50% of their budgets simply by dropping the seldom- or never-used features of their systems.
Kent Beck (the founder of Extreme Programming) says it best:
“Software development has been steered wrong by the term ‘requirement,’ defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing change. And the word ‘requirement’ is just plain wrong.
“Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10, or 20 percent, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or obligatory.”
OK. So the word “requirement” is plain wrong. But if they’re not requirements, what are they?
Let’s Call Them Features
I like the word feature:
It doesn’t have any of the baggage carried by “requirement.”
Everyone knows what a feature is.
It is something you can have a conversation about with your customer.
And it just avoids all the drama that comes with “requirement.”
Now as much as I like the word features I don’t necessarily use it all the time (at least not initially). There’s simply too much history wrapped up in the word, so it’s sometimes handy just to go ahead and use it for the sake of communication or to make a point.
But the sooner you can get your customer thinking in terms of features they would like to see in their software (and less in terms of absolute requirements) the better. It will give you and your team the wiggle room you’ll need to balance all the conflicting trade-offs and forces that come with building interesting products, while enabling you to focus on the really important stuff first.
So Let’s Drop the Word “Requirement”
It’s plain wrong. It runs counter to the spirit of discovery that comes in building great software and it sends the wrong message (that everything has to be in there).
If you can get your customer talking about the “features” they would like to see in their software and then focus on how to best deliver the most important 20%, you’ll go a long way to ensuring that your customer gets the biggest bang for their buck—and you’ll never have to worry about not delivering something of value.
Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.