I’ve been spending a bit of time lately writing new material for the requirements capture course we run at work as part of an attempt to revise the course to make it reflect modern techniques and best practices. While I was doing this I found an introduction to user stories that I wrote during my previous project when I began pushing an agile approach to get us to moving forward.

Reflecting on it, it seems like my approach to user stories is influenced mostly by Kent Beck (eXtreme Programming) and Alan Cooper (Interaction Design), and ends up much more verbose than the behaviour-focused style of Dan North. With this verbosity comes a finer level of detail, and I’m beginning to really see how complementary these techniques - specifying behaviour at a high level to guide the project and creating detailed user stories just-in-time - are. With that in mind, and given the current interest in BDD (If you haven’t heard of BDD check out Dan North’s articles at http://www.dannorth.net), here’s my diatribe on user stories.

The development of user stories from our requirements gathering meetings is an attempt to capture typical patterns of usage; I am not necessarily attempting to capture every possible pattern of use, nor am I necessarily attempting to enunciate every system response. The goal of my user stories is to allow me to identify the major entities in the Respondent module and the major activities performed on them, and to begin developing the Respondent module based on this knowledge.

Once this effort has resulted in an initial prototype of the Respondent module, it is anticipated that the application itself will serve as the main vehicle for identifying the outstanding requirements - When it is released it should fulfil its major functions (as specified during previous meetings), which industry studies suggest to be around 80%. From this point a number of incremental releases can be used to:

- Identify what is lacking. It is typically easier to identify what is missing from a product than to identify what is missing from a description of a product (and then to hope that your perception of the description matches with that of the person building it);

- Provide feedback on interface design. With a number of releases planned within a short space of time there is much more scope for making both large and small changes to the design of the application;

- Provide additional scope for defect identification, defect removal and regression testing. Providing a number of releases will provide the ability to release bugfixes alongside additional functionality, which provides scope for both verifying that the defects have been resolved and ensuring that this has not introduced additional issues;

- Prevent 'analysis paralysis'. A common occurrence during the requirements gathering phase of any complex system is an extended length of time being taken to finalise requirements because - since

the system is complex - we want to get them right. This is a major cause of failure in IT projects, and the use of 'lightweight' development techniques is one way to prevent it. Because we intend to release a number of versions of the Respondent module, each delivering incremental improvements over the last, at any point we can decide we've expended enough effort on the module and cease work on it - with a completed (although not necessarily 100% completed) application to show for it. This incremental approach is based on the common application of the Pareto principle to IT systems (that

the first 80% of the functionality requires 20% of the effort, and the remaining 20% of the functionality requires 80% of the effort); and

- Provide scope for changing requirements. Because the initial releases of the Respondent module will be focussed on delivering the most commonly-used functionality (which, by its nature, is less

likely to undergo change than the less-core parts of the module), requirements for peripheral parts of the module will be free to undergo change at no (TA) cost until their requirements are defined.

This concept of "Just-in-Time Requirements Analysis defines requirements only when they are needed – and only at the detailed required. It is an iterative process that expects and embraces change and makes it easy for requirements to evolve over time ... This allows development to begin with incomplete requirements and also provides a mechanism for incorporating feedback from actual development into analysis. The end result is a shorter project life cycle, better requirements, less risk, and an evolving baseline that meets the changing business needs of customer." (Michael Lee, The Agile Alliance).