Big organisations are addicted to requirements, because having requirements allows them to believe that they can plan ahead. The more requirements, the more planning can be done, and this is obviously a Good Thing. Perhaps requirements are the key interface with the customer, perhaps they have contractual significance.
Organisations become so invested in requirements as the bedrock of planning activity that ticking off requirements as they are satisfied becomes essential for measuring 'progress'.
But let's back up here. There's that term, 'plan ahead'.
A key insight of Agile is that effort invested in planning ahead is frequently wasted, because development of a complex system results in unpredictable changes to detailed ( and sometimes not so detailed ) requirements. Planning ahead in excruciating detail does not necessarily de-risk a project - it can do the opposite, and frequently does.
I'm not arguing that there should be no product vision beyond what's achievable in the next sprint. This is absolutely not the case, and developing and managing that vision is perhaps the key thing that the Product Owner is responsible for.
But I am arguing that an Agile development process cannot make any meaningful measure of 'progress' simply by comparing 'done' requirements with the wish list you started with at the beginning of the project, because that list should have evolved in parallel with the software.
Scrum says "Only what has already happened may be used for forward-looking decision making." But my argument here is that this is frequently misinterpreted to mean that looking backwards will tell you how far you have to go. This simply isn't so, and it highlights a very very fundamental shift in perspective that Agile drives - your product is a moving target.
This is a Big Idea, but it's one that all of Agile revolves around.
One way to view Agile is as a set of principles that enable product to be built in these circumstances. The implication of Agile is that as soon as you have a coherent set of features/functionality, you can release it regardless of the fact that there are still unsatisfied requirements, because all that functionality is done. You are never, in fact, aiming to satisfy all the requirements. You aim to deliver sensible product increments.
Of course, you are rarely in a perfect Agile world. It's often the case in practice that there are requirements for your product as a whole that you have no control over. They may be imposed by regulation, they may be contractual, they may simply reflect physical reality. They don't necessarily correspond to a particular story as delivered by a particular team, as they are properties of the product as a whole.
This sets a trap, because focusing on individual stories, even though they are 'done' and working, will not tell you where your product stands. You have to look at a bigger picture.
Therefore, from a product perspective, it's normal to be in a situation where you have a set of new, completed, shippable, stories but together they do not yet form a thing that you wish to release. 'Working software' means that no more work is required on the set of 'done' stories delivered by the sprint, it other words it means 'these stories could be shipped', not 'these stories will be shipped NOW'.
Steering the product ship through the product increment streams to the point ( or points ) of delivery is a project management/Product owner responsibility, and an awareness of unsatisfied requirements is very important for this purpose.
So in other words, in an Agile environment looking backwards at requirements met so far is not a reliable guide to how far you have to go. The sense in which this perspective does provide useful empirical data is the thing that Agile calls 'velocity' - an abstracted measure of the rate at which work can be done.
Focusing on unsatisfied requirements ( which will not be a static set, even if there are predetermined elements ), and being aware of velocity, provides essential information for Product owners guiding the evolution and actual delivery of the product.
© Mark de Roussier 2021, all rights reserved.