{'fraction_non_alphanumeric': 0.02242152466367713, 'fraction_numerical': 0.003843689942344651, 'mean_word_length': 5.298387096774194, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The Many Lives of an Agile Story: Design Processes, Design Products, and Understandings in a Large-Scale Agile Development Project

In Agile Software Development (ASD), stakeholders use stories to stimulate conversations that create and convey understanding of software requirements. Some authors have argued that ASD methods have limited applicability to large-scale projects because agile stories are not sufficient to capture the complexities of up-front design. This paper reports a 2.5-year field study of how an ASD team for a complex software system adapted the user story concept and the Scrum approach. The team sought to create a convention for representing agile stories which could capture the complexities of the system requirements without burdening the team with unneeded documentation. They developed eight different ways to represent a story. The core representation of the approach was called a HyperEpic, a structured collection of closely-related HyperStories. HyperEpics required 90-99% fewer words than conventional specifications. Because of their dense form, Hyper-epics were not useful for other phases in the design/build processes. The team evolved a design/build work practice that proceeded in stages. In each stage, stories underwent a one or more transformations. Each transformation represented stories differently to create varied kinds of understandings among different stakeholder sets. The team was able to gain the benefits of ASD - faster development cycles, less documentation, rapid adaptation to insights and conditions.