Category: Requirements

There are many things that are different in the “new world of development” as opposed to the way it was in “the old”. One of the more subtle, but perhaps fundamental is the way that decisions and communication has switched characteristics.

When a developer was developing code “in the old days” he or she had a task defined by some designer, project manager or architect. This was usually the only point of communication that was available to discuss the features. But frequently sales persons or other customer contacts would show up at the developers desk and ask about some features, estimates or changes that could be made “since doing them at the same time would not cost anything”. This single-point communication, multi-point control has been one of the primary sources for unpredictability in the “old” way. Although detailed plans was made and project managers tried everything possible to keep them, the urge from business to rush and push unplanned things into the workload of development ensured failure to meet the plans, no matter how strict control was applied.

In agile development one of the most important techniques is to enable developers to communicate with stakeholders of various kinds, users, customers, business people. This multi-point communication is essential to ensure that valuable features are developed. On the other hand decisions are focused around the product owner and his power of prioritization. This is exactly enough to work as a single point of decision. In conjuction with the multi-point communication it is “right-sized” decisions.

So removing the single-point communication, multi-point control and replacing it with single-point control, multi-point communication gives us controlled flow of tasks and predictability of development.

“Do you have a pen?” … After a few minutes the answer is “Sorry, no.” What if the question would have been “Do you have something to draw with?”. Maybe a pencil, or chalk could have been found. And better yet, “I need to draw. Do you have a pen?” This signals not only the need, but also a prefered set of properties on the solution. These properties are not requirements, but can still be used as input.

Does your requirements process work like this? Or do you have “Must Have”, “Could Have” and “Nice to Have”? It is the need, and the implied and fuzzy priorities, that is the essential part of agile requirements management work. These are seldom articulated in standard requirements mangement processes.