Have you ever considered that “requirements” are bad? I am not talking about poorly written, or bad requirements, but rather the concept of requirements altogether.
I am asserting that working from “requirements” leads to the wrong product and a focus on outputs – both of which are ineffective, old-school thinking, and are NOT Agile.
The Wrong Product
How can requirements lead to the wrong product? You have great data, user feedback, and smart people that pull all that together into a set of requirements. You are confident about what users / stakeholders want and need, so how can these requirements be bad?
Have you ever considered that you're not really working with 'requirements,' but rather everything in your backlog is merely an assumption? Click To Tweet“Requirements” is so definitive – it presumes to be right in the beginning, which you [should] know is rarely true. Do you think Albert Einstein presumed he was right about anything he moved forward with? Not likely. Rather, I believe he made educated assumptions and proceeded to validate those assumptions.
Value is measured post-deployment. Did it make money, save money, satisfy users, etc.? You validate how effective the deliverable is based on the outcome it produces. To determine if that feature should be developed in the first place, you make some assumptions and estimates up front. You think this requirement would produce ‘x’ and satisfy ‘y’, but those are only assumptions. You can never know if you are right until you validate it.
“Requirements” presumes that something is required. But is it really?
Would you still call them “requirements” if the delivered thing made no money, lost money, or upset users? Would you still say those things were “required” to be done? Or would it make more sense to say that you developed something based on an assumption that merely proved out wrong?
Agile enables its followers to work empirically – do, experience, learn, and adjust. The intent of Agile is to discover what the right things are and deliver them more frequently. The smaller the assumption and the quicker you can deliver it, the faster you can learn and adjust. That is how you deliver the right things, faster.
The Wrong Focus
Working from “requirements” creates a “feature factory” environment focused on productivity (outputs). You have a list of requirements (features) and the goal is to deliver them as quickly as possible, all of them. Teams flock to Scrum, for example, because it enables them to burn through requirements in short sprints. The goal is productivity output – how many stories can the team deliver each sprint and how quickly can they deliver the full list of requirements? The team is a feature factory, measured by its productivity. Despite the popularity of this approach, it is NOT Agile.
Think Differently
The mindset shift to consider is that your user stories or backlog items are not requirements, they are assumptions. This means you will use discovery to seek the right things (outcomes) rather than burning through a pre-defined checklist (outputs). Your team should be testing assumptions with everything it delivers, not claiming productivity victories. The question is, are you learning and adjusting from it? If you embrace the empirical process (which happens to be what Agile is all about), you can only work empirically if you see your backlog as assumptions. Therefore, “requirements” are bad.
If you found this blog insightful, you’ll love “What a TV Series Can Teach Us About Software Projects.”