Agile Processes in Software Engineering and Extreme Programming- P8

Agile Processes in Software Engineering and Extreme Programming- P8:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P8 The Application of User Stories for Strategic Planning Lawrence Ludlow Intelliware Development Inc., 1709 Bloor Street West, Suite 200, Toronto, Ontario, Canada M6P 4E5 lawrence@intelliware.ca Abstract. In agile development stories are typically used to define small, inde- pendent pieces of functionality that have value for the customer. They are most often used to define requirements for future development. This paper describes a project where stories were used on a much broader scale as part of a strategic planning exercise to identify a long-term development roadmap for a new sys- tem. Stories were used not only to define what needed to be built but also to document existing functionality and gaps with current systems. This resulted in the generation of a large number of stories, which created challenges with man- aging and keeping the stories up to date as the project proceeded.1 IntroductionThis experience report describes how user stories were utilized as a key component inthe development of a strategic roadmap plan for a new system. A roadmap representsa comprehensive plan for a development exercise to address a particular business is-sue or objective. A roadmap can be used as part of a business case to secure fundingfor a project or as the starting point for more detailed planning and development. A user story is defined by Beck [1] as “Something the system needs to do. Thestories are written on index cards, with a name and a short paragraph describing thepurpose of the story.” Jeffries et al. [2] also defined a story as “…a short descriptionof the behavior of the system, from the point of view of the user of the system.” Forthe project described in this paper stories were used for requirements for the newsystem plus also functionality provided by existing systems and known gaps withthose systems. The existing function and gap stories established a baseline forfuture planning. The client company was a large international financial services firm that was cre-ated by a joint venture involving divisions of two large banks. This resulted in the cli-ent’s internet presence being delivered by several existing, disparate systems eachproviding differing levels of functionality and appearance. The objective of theproject was to develop a roadmap for a new enterprise-wide Web portal capable ofdelivering a consistent user experience to all of the client’s customers. Intelliware wasengaged by the client group responsible for defining and delivering the new Webpresence and interfacing with other key stakeholders, such as senior management andproduct group representatives.G. Concas et al. (Eds.): XP 2007, LNCS 4536, pp. 198–202, 2007.© Springer-Verlag Berlin Heidelberg 2007 The Application of User Stories for Strategic Planning 1992 Project Approach and MethodologyThe project was split into four main phases:1. Internal State Assessment – Documentation of current capabilities and known gaps2. Future State Engineering – Documentation of high level Strategic Alternatives3. External State Assessment – Third party investigation to define best practices for an online client experience4. Strategic Options – Identification of project options and development of a high level plan for the preferred Strategic Alternative Stories were used during all 4 phases of the project, resulting in nearly 900 storiesbeing identified. The following sections summarize each phase.Internal State Assessment. Internal state involved the identification of currentfunctionality and known gap stories. The existing systems were reviewed in detail andstories were written for each major piece of functionality. The resulting currentfunctionality stories were then validated by reviewing the cards with key operationsand business representatives. The cards were updated as needed and the final versionswere posted on the project Web site for further review by the client. Also, existing product and system documentation was reviewed and stories werewritten for the functional gaps that were identified. Follow up reviews were held tovalidate the gap stories with managers from the appropriate product groups. New gapstories identified were added to the overall list and posted on the project Web site.Future State Engineering. Future State Engineering involved weekly meetings withclient representatives to discuss future requirements and write stories. Once an initialset of stories was identified, product experts were brought in to review the storiesrelevant to them to ensure their known future requirements were represented. Towards the end of the Future State phase s ...