The other evening, I was getting ready to attend a Meet-Up that I have not been to before. Obviously, knowing where the meet-up was being held was a key requirement to successful attendance; so, I checked the meet-up site before leaving and programmed my navigation system. Upon arrival, the venue (a restaurant) was closed and the parking lot was empty. Trying to figure out what was happening, I posted a comment on the site. Soon two others arrived, and were as surprised as I was about the current circumstance. Shortly after that a reply was posted that the meet-up was actually at another location, and had been for a few months…..a short drive later, I was at there…
This situation highlights a common problem that relates to the Agile principle quoted above. There was a requirements change [the venue], which had occurred about 3 months previously. But the most accessible information about this key requirement was out of date. On that particular evening it was not a “changing requirement” it was simply wrong.
Similar scenarios can be used to illustrate incomplete or even missing requirements. I am not referring to the “unknowables”, but rather to those items which are known (or could feasibly be found out) which are not recorded and shared so that the team is aware of them.
Gathering what is known, even if only as a possibility/probability provides significant value. At the very least it provides a point of reference for actually identifying changes. As a general rule, the practice provides much more. Seeing even potential requirements helps trigger thought processes and often has tangible impact on decisions.