I think everyone who participates in Scrum ought to know the essential laws that Scrum was created to deal with. But much more important, I think that the client must acknowledge them, since I do not believe it is possible to be successful at buying software without being fully aware of these fundamental laws, coping with which is of utmost importance when it comes to developing software. It never hurts to remind oneself of the laws, that Scrum was created to deal with:

Specifications and requirements will never be fully understood (Ziv’s law)

Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.

The users will never know what they want until the system is in production and maybe not even then (Humphrey’s law)

The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.

An interactive system can never be fully specified nor can it ever be fully tested (Wegner’s lemma)

Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.