Requirement Quality
History
Requirements are often pointed to as the problem when a project doesn’t deliver the hoped-for business benefit. “The requirements are wrong”, “the requirements don’t reflect the needs of the business”, “the requirements are confusing” are some of the usual complaints.
When we dig deeper into these statements we find a few recurring themes:
The core business need wasn’t communicated effectively to the project team
The business need changed before the project could be delivered
Different departments had differing, sometimes conflicting, needs
The requirements are “signed off” but not thoroughly considered
What was developed does not align with the “spirit” of the requirements
Problem Statement
It sounds as if there are a number of problems here. They all lead back, ultimately, to the idea that the project does not deliver a solution to the actual business need.
One fundamental issue with typical projects is that once the charter is set, it is incredibly hard to introduce change to the direction of the project. The reality of business, however, is that needs change, sometimes very rapidly. When the project is deliverer, it is not evaluated against the initial need, but the current state need at the time of delivery. The requirements may not be “wrong”, so much as they no longer reflect current need. Project methodologies encourage this dissonance.
Agile solution
What will Agile delivery methods do to help with requirement quality? Agile methods are about delivering small, meaningful chunks of useful functionality change to end users quickly. Agile methods also encourage a user feedback loop, “did we deliver what you need, and if not, what needs to be different?” Agile methods encourage active participation of the business in the entire delivery cycle, not just requirements dictation followed by waiting for User Acceptance Testing many months later.
By going Agile, the business reduces the problem of core need not being understood. The team is very quickly delivering against the need and asking if the deliverables are meeting the need. Correction to deviation from the current need is encouraged.
The very nature of Agile is that it does not allow for long durations between definition of need and delivery of solution. As business needs change, the next deliverables easily adjust to support those changes, quickly and accurately.
Differing opinions on needs are a reality. Departmental agendas, conflicts of KPIs and other reasons can all drive conflicting requirements. While an Agile development approach can’t stop the underlying issues from occurring, the Agile approach exposes those issues early, so they can be addressed by the business. Fast delivery of small increments of change means that the business is all focussed on that small increment at the same time, forcing scrutiny.
Epic tomes of requirements are the cornerstone of waterfall projects. If the document isn’t many hundreds of pages long, everyone thinks the document must be missing something. It is all but impossible to ensure that these massive documents are complete and internally consistent. They are also very difficult to be fully understood. The review process, by default tends toward a ‘Rubber Stamp’ process where reviewers all hope someone else will catch the errors, so they sign off after reading only the parts they believe are critical to them. Agile, by its very nature, is diametrically opposed to these massive documents. Agile is about documenting one or two changes and then implementing them, then adjust and add more changes, over and over again. No massive documents are needed, no painful reviews are needed.
“The requirements didn’t say that” and “But they meant that” are frequent complaints and counters with traditional projects. Both sides of the argument are often correct, which is the crux of the problem with massive requirements documents. By going Agile, as each requirement is discussed, designed and delivered, it can be evaluated quickly for Spirit vs Letter, ultimately ensuring the right change is delivered regardless. The Spirit vs Letter argument is rendered moot.
The Agile approach to change delivery is about higher quality. Requirements become less of an issue than they were with traditional waterfall projects because they are tested early and often. Users get to see the results of their requirements early and they get to refine them to meet business needs much more quickly.
