Tonight, at the North Bay Agile meetup, I facilitated "The Great Requirements Showdown!"  It's an experiential exercise that pits traditional written requirements against the agile alternative: user stories and face-to-face communication. 

During the workshop, participants wrote down their 'Ah Ha!' moments and we shared and talked about them.  Here are they are:

• Too much detail is at least as bad as too little.  Time-boxed "good enough" requirements work better.
• One group (requirements writers, in this case), trying hard to do a good job, can actually cause harm by using up too much of the schedule.
• Teams working on the requirements (upstream process) used up most of the time, leaving the developers (downstream process) with little time to turn the requirements/specs into a product.  Great requirements are worthless if there is no chance to implement and ship.
• Late commitment resulted in poor deliverable.
• Integrating even small increments of work can be more difficult than it seems, and lead to a poor quality 'whole'.
• We wish we would have used continuous integration!
• What is important is not always obvious.
• We didn't have enough context or vision to know what really mattered and what didn't
• Optimize the process to focus on what is most important.
• Ask the customer!  Find out what matters most to the customer, don't assume!
• We never thought to consult with the customer!  Why is that?
• Face-to-face communication between the developers and the requirements team resulted in much higher product quality than using written communication.
• Feedback is a good!
• Feedback is everything
• Positive feedback, especially confirmation of "done" is important.
• Without feedback, the process and the results suffered
• Use all available means to communicate (In this case we wish we could have used drawing in our requirements).
• Precision in language is really important (and really elusive).
• Verbal instructions leave open ambiguity, which sometimes gets translated correctly.
• Sometimes set-based development (working on multiple solutions in parallel) is a good way to find the best possible solution.  Watch out for emotional reactions from the people whose solutions aren't chosen. 
• I hadn't ever thought about set-based development as an alternative to pair-programming.
• Serendipity!  Sometimes you just luck out and build it right.
• Sometimes the end product matches the requirements by accident!
• Good requirements speed up development, like a good road map.
• Requirements done quickly are ambiguous.
• Perspective matters!
• Simplicity!  Focusing too much on the details can distract you from the big picture.
• Pair-programming concepts can be applied to creating requirements documents.
• Communicating only in writing leads to 'us' and 'them', collaborating leads to 'just us.'

Have a comment or question about any of these?  Leave a comment and share your thoughts.

Cheers,

Chris