Conditions of satisfaction

February 25, 2007 by Artem

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 , I want [so that ]". For example, "As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load". This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.

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?

Permalink