Ask Five Times Why
|Risk Map||Risk Map|
|Getting Started in Agile||Getting Started|
Enquire into the reasons for each requested feature
Where the requirements are presented in the form of a solution to a problem, ask “why?” to find what problem the solution solves.
See also Five Whys – what is essentially the same technique, but applied to root cause analysis.
Ask Five Times Why (The origin of the technique is much older than suggested in wikipedia)
Spotting a requirement that is giving a solution to a problem is a bit of an art. The distinction is between what must happen to fill the goal of the user, and what is one way to make it happen. Users like to be helpful and give the solution, but if the developers accept that as a requirement, they lose flexibility and might be forced to write the system as a whole series of ‘special cases’ to implement these requirements. If the developers ask "Why?", the requirement is moved to a more abstract purpose that might have several solutions. The developers are generally better positioned to decide which of the solutions is more appropriate given what else also needs to happen.
Where users are permitted to give specific ‘solution’ requirements is when describing how they want to interact with the system. This desired interaction is often captured in the form of a scripted dialog known as a Use Case. Yet even here the "Requirements" should be open to negotiation. As one observer said, "It is surprising how many requirements turn out not to be required once the price tag is known"
This practice is also, and more commonly, used in Root Cause Analysis (see Five Whys) , to delve into the root causes of why things happened as they did.
- Agile Requirements Challenge #7. Project Stakeholders Prescribe Technology Solutions