One of values of the Manifesto for Agile Software Development is that you should prefer “responding to change over following a plan”. This introduces a lot of uncertainty in Scrum projects. In his book “Executable Specifications with Scrum”, Mario Cardinal explains that to manage this uncertainty, you have to build your project on a stable platform.
This chapter explains that to solve the right problem, you must first learn to distinguish the requirements from the solution. Then you must recognize the impact of uncertainty when describing requirements. This is because it is challenging to describe what needs to be built while embracing change. Finally, you can conclude that the current practices inherited from traditional engineering are inadequate in this regard. When requirements are difficult to grasp and are in constant flux, you must tackle uncertainty in a nontraditional manner. Executable specifications with a Scrum framework proved successful.
Software is built to solve complex problems. It is naive to believe that you can write all the requirements from the start and then plan accordingly. Experience teaches you that it does not work this way. It is not realistic to think that requirements are just out there somewhere, and the only thing you need to do is get explanations from stakeholders. More often than not, stakeholders do not know exactly what they want. And if they know what they want, unfortunately they do not agree among themselves. As noted in Chapter 1, “Solving the Right Problem,” when faced with ambiguous requirements, you must stop using traditional management practices and start tackling uncertainties differently.
As strange as it may seem, to master uncertainties, you should start by identifying the certainties and the thing that will hardly change. Those certainties are not requirements. They are guardrails that ensure a solution can be built. They create a stable foundation on which you can rely. They simplify the specification work and ensure you never end up in the zone of total chaos.
Source: Executable Specifications with Scrum – A Practical Guide to Agile Requirements Discovery, Mario Cardinal, Addison-Wesley Professional
To input some stability in Agile software development projects, Mario Cardinal, proposes the concept of guardrail. A guardrail is something that rarely changes and which should be used as a guide to assist in decision making. Here are some of the proposed guardrails:
* A shared vision
* A meaningful common goal
* A set of high-level features
* A “can-exist” assumption
It is important for the projects to create some stability with a high-level definition of the boundaries the problem to solve. Then you can start to gradually reduce the uncertainty with the exploration of the possible solutions for your problem.