#43-The Four Quadrants of Requirements

This episode will introduce a useful framework for organizing requirements as the are identified.  Such organization can be very helpful in collaboration and validation throughout an agile process.

Transcript

The Four Quadrants of Requirements

One of the virtues of an agile approach is the ability of the team to respond to real business value. Part of this comes from the incremental nature of such an approach, which allows the business to re-prioritize those requirements throughout the process of development.

Another benefit that comes from incrementalism is the ability to validate the work as it is completed, and to make quick corrections before errors can compound. But for this to work effectively one must know whom to approach when validating each feature or other completed work item.  Also, if we fail to properly identify such a resource, we may make mistakes that go undetected.

This means that we need an effective way to identify the source of a requirement, and therefore the proper resource for validation in each case.  I am going to offer a framework for this, one I have used with many of my consulting customers, and which has been quite beneficial to them.

Where do requirements come from?

We normally think of requirements as coming from "customers", and that is true as far as it goes. But actually, requirements come from many places.   See my previous “Agile Tip #25-Enumerate Your Stakeholders” for examples.  It's available in the backlog.

I like to think of requirements as coming from two general sources. There are business sources: end users, project sponsors, subject-matter experts, business analysts, project managers, product owners, regulators, and the like. There are also technical sources such as: other teams that might depend on the current work being done,  developers themselves who have requirements about their environment and the efficiency of their daily work, and also a set of professional standards that arise from the technical world but are really only visible to them.

Think of a hospital.  The administration drives the work of those they employ, and therefore the requirements that define that work, but also the medical professionals (doctors, nurses, technicians) have their own standards that come from their education and experience.   Both are important, of course.

Also, requirements arrive in two different time frames. There are the requirements that are before us now, and there are requirements that have to do with a possible future that we can be made aware of, or hypothesize about.

This produces the four quadrants of requirements:

                         Now               Future
Business          1                        2     
Technical        3                       4

Quadrant 1 is what we normally think of as "requirements". Leadership has approved a particular feature or product, and this represents effort that should be expended in the present time when it becomes prioritized for an iteration of work.  Identifying a requirement as quadrant 1 means that there is no question about its development, only the sequence.  Also, it means that leadership is the source for validation.

Quadrant 2 has to do with planning for the future. Often the business has short- or long-term plans that we can take into account when developing products, to make sure that we have not made it difficult to expand those products when those future requirements arrive.  A business today may be delivering products only on a single hardware platform, for example, but has plans for the future to expand to other platforms, opening up new markets when it makes sense.

Quadrant 3 are the omnipresent standards that the technical people must adhere to, in order to ensure that the quality of their work will allow the agile process to "embrace change".  Failing to see these as absolute requirements can and has caused significant economic damage in the past.  The Y2K bug is a good example, but a quick look around the internet will provide countless others, some of them quite sobering.  Automated systems govern much of the quality of life in the modern age, and this shows no sign of slowing down.

Quadrant 4 is where things can get controversial. These are ideas that the business is not asking for today, has not said they are planning for tomorrow, but are things that the team can imagine as valuable because they are intelligent, experienced, dedicated people. And while we will not develop those products because we don’t want to do anticipatory work that is not budgeted for, we also don't want to lose good ideas, insights, and innovation, nor fail to elevate them to management for evaluation. It's part of the value of the teamwork we engage in.

Knowing which quadrant a given requirement or insight belongs in can help us to know where, when and with whom we should collaborate. It also helps us to identify the proper resource for validation as the work proceeds.

Quadrant placement is part of the analysis process and should be engaged in collaboratively.  If Acceptance Tests are being written by the team, this is a good place to do it.