Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he’d like to see) the feature requests are often expressed in a form of “As a
At the iteration start, when the team selects user stories or features to be implemented, the requirements have to specified in the bigger detail, while still omitting as much implementation as possible until the actual start of the development. The agile term for these additional level of details is “conditions of satisfaction”. For the above administration requirement example conditions of satisfaction might specify which parameters of the system the administrator needs to monitor (e.g. processor load in %, free network bandwidth in KBits per second) and how would he like to monitor the system (e.g. be notified by SMS, see the load himself when running the administration panel).
There are couple of simple questions that can aid creating the helpful conditions of satisfaction (adopted from Writing Contracts for Agile Development )
– How will the team know weÃ¢â‚¬â„¢re done?
– When the team demonstrates this feature to you what would you like to see so that you know the team has done what you expect?
When do you usually specify the requirement details and what level of detail do you find useful?