Please cite as: Onions, P.E.W. and Patel, C. (2009) “Enterprise SoBA: Large scale implementation of acceptance test driven story cards”, IEEE International Conference on Information Reuse and Integration (IRI 2009), Tuscany Hotel, Las Vegas, August 10-12 Enterprise SoBA Large-scale Implementation of Acceptance Test Driven Story Cards Patrick Onions, Chetankumar Patel Leeds Metropolitan University’s Centre for Project Management and School of Computing p.onions@leedsmet.ac.uk, c.patel@leedsmet.ac.uk Abstract Agile software development has proven to be an effective alternative to the regimentation of waterfall- based approaches. Recent research by Patel and Ramachandran [17] has led to the innovation of Acceptance Test Driven Story Cards (SoBA). Implemented using Extreme Programming, preliminary findings show SoBA retains essential Agile attributes like feedback, flow and universal responsibility for quality [3] whilst delivering improvements to estimation, communication, requirements gathering and testing. Original SoBA theory was exploratory, and its validation was experimental systems development. Enterprise software on the other hand is more complex and architectural in its design. This paper suggests integration with architecture, project management and business analysis practices in order to expand SoBA’s potential and address criticisms of Agile methods and Extreme Programming; particularly instability of requirements, user conflicts and scalability. Enterprise SoBA is untried. This paper proposes high- level abstract concepts and integration, and these will be tested during the course of ongoing research. 1. Keywords Extreme programming, story card based agile software development, acceptance test driven story cards, SoBA, enterprise software development, project management 2. Introduction Preliminary research into the Acceptance Test Driven Story Card (SoBA - S to ry card B ased A gile software development) [17] has revealed this concept to be highly effective in supporting requirements elicitation. SoBA enhanced the traditional story card [2] through introducing a focus on stakeholder involvement, adding acceptance testing and other details to the story card, and modifying the requirements elicitation process. These innovations and enhancements were intended to improve estimation, improve communication between customer and developer, identify verifiable functional and non-functional requirements, support gap analysis, enhance the consistency of documentation, and integrate testing into requirements gathering. Initial empirical experiments have revealed this to function correctly and deliver intended benefits. Initial empirical experiments have revealed the original SoBA concept to function correctly and deliver intended benefits. Preliminary work focused on theory development and empirical testing in three small-scale software development projects. Enterprise software development however tends to display complexities that defy conceptually solid methods. Analysis reveals further enhancements could improve SoBA’s suitability for large-scale systems whilst retaining its key attributes and benefits. This paper proposes to address scalability, flexibility, management and control, concern for all stakeholders, integration with development and implementation processes, version control, configuration or change management, and intellectual asset management. Areas of integration and implementation will be considered but not prescribed since this is ongoing research and so as to remain flexible and relevant to a broader base of applications. 3. Agile requirements engineering practice This paper will treat Extreme Programming (XP) concepts and practices as illustrative of Agile methods. It will span the breadth of requirements engineering practice, which SoBA has been designed to effectively encompass. Requirements engineering is divided into three practices in XP: the planning game, release planning, and iteration planning [2]. Usually projects comprise several iterations for each release, but iterations can also be released individually depending on project scope [2]. Figure 1 below summarises XP’s requirements engineering practice. Requirements elicitation is undertaken during the planning game, and responsibility for this activity lies largely with the client. System requirements are collected using story cards written by the customer, not by a programmer. The customer defines the value with the intention of the programmer building that value.