DOCSLIB.ORG

User and System Stories: an Agile Approach for Managing Requirements in AOSE

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
User and System Stories: an Agile Approach for Managing Requirements in AOSE Main Track AAMAS 2021, May 3-7, 2021, Online User and System Stories: An Agile Approach for Managing Requirements in AOSE Sebastian Rodriguez John Thangarajah Michael Winikoff RMIT University RMIT University Victoria University of Wellington Melbourne, Australia Melbourne, Australia Wellington, New Zealand [email protected] [email protected] [email protected] ABSTRACT A User Story is a brief informal description of a feature described The agile software development life cycle is widely used in industry from the perspective of a user of the system. For example, for a today due to its highly flexible and iterative processes that facilitate bookstore system: As a customer, I want to search for books by rapid prototyping. There has been recent work in bringing concepts keywords, so that I can find the book I want. and processes from agile methodologies to agent-oriented software Some of the key benefits of using User Stories are that they[8]: engineering (AOSE). We contribute to this effort by presenting in are comprehensible by both the users and the developers; enables this paper a novel approach to capturing requirements of agent better scoping of requirements; encourage deferring details until a systems in AOSE using and extending agile concepts. In this paper, better understanding of the needs are established; and promote a we propose to adopt and extend the well-known concept of User greater understanding of the domain specific concepts and logic by Stories to facilitate the development of agent systems. We introduce the system developers. a novel concept, System Story, that defines requirements from the In current agent development methodologies such as TDF [16], perspective of the system. These System Stories are refinements of Prometheus [25], Tropos [4], O-MaSE [11], INGENIAS [26], and User Stories and provide more intuitive mappings to agent concepts ASPECS [10] the process of managing requirements from elicitation in the design and implementation. We show how our approach to implementation follows the more traditional way of developing allows better traceability of requirements between stories and the software, rather than the more modern agile approaches. different software development artifacts. We validate our proposal Most of the agent methodologies use concepts and techniques with a feature-based comparison to recent related work, and a that are foreign to the domain experts and end users. The initial preliminary user evaluation based on a drone simulation of a simple stages of gathering the requirements of the system are often cum- search and rescue case study. bersome and require extensive modelling to map the requirements to suitable artifacts of the respective methodologies. KEYWORDS In this article we present an approach that not only adopts the concept of User Stories, but also extends the concept to System AOSE; Engineering MAS; Agile methodologies Stories, which capture features from the system’s perspective, con- ACM Reference Format: sidering the system as a first class citizen. In our approach, we refine Sebastian Rodriguez, John Thangarajah, and Michael Winikoff. 2021. User User Stories to System Stories. For example, w.r.t to the User Story and System Stories: An Agile Approach for Managing Requirements in above, a System Story might be: As the System, I want to index all AOSE. In Proc. of the 20th International Conference on Autonomous Agents the books by keywords, so that I can retrieve them by keyword. and Multiagent Systems (AAMAS 2021), Online, May 3–7, 2021, IFAAMAS, 9 pages. These System and User Stories are mapped to AOSE design artifacts and corresponding constructs in an agent programming language. 1 INTRODUCTION Although there has been recent work on agile AOSE methodolo- gies (e.g. [5, 33]), they do not include System Stories or acceptance The agile software development life cycle (SDLC) is widely used in criteria, the conditions under which the system behaviour can be industry today. In 2017, 71% of the organizations consulted in [27] accepted by the stakeholders. Our work, by including both these responded that they use agile approaches in at least some of their aspects, provides a richer approach with better traceability. projects. The agile approach encourages a flexible and iterative We hypothesize that the agile approach we propose will provide process that generates rapid prototypes that are continuously re- a more natural and flexible way to managing requirements that are: fined. This involves much more interaction and collaboration with (i) easy to understand; (ii) mapped to the agent design concepts the users and developers of the software system. The core values that realise them; (iii) easier to maintain; and (iv) allow traceability expressed in the agile manifesto [2] are at the center of this success. from execution to requirements. There has been recent work in bringing concepts and processes Our approach is general and complementary to existing AOSE from agile SDLC to agent-oriented software engineering (AOSE) [5, methodologies. For the purpose of illustrating our approach we 21, 22, 31, 33]. We contribute to this effort in this paper - we present use in this paper the TDF (Tactics Development Framework) agent a novel approach to capturing requirements of agent systems in design methodology [16] and the SARL agent implementation plat- AOSE using and extending agile concepts. form [29]. The choice of these tools are due to the fact that they Proc. of the 20th International Conference on Autonomous Agents and Multiagent Systems are used for an industry project that necessitates this work. (AAMAS 2021), U. Endriss, A. Nowé, F. Dignum, A. Lomuscio (eds.), May 3–7, 2021, Online. In this paper we: (i) present an agile approach to capturing the © 2021 International Foundation for Autonomous Agents and Multiagent Systems requirements via User and System Stories (USS); (ii) show how USS (www.ifaamas.org). All rights reserved. 1064 Main Track AAMAS 2021, May 3-7, 2021, Online map to agent concepts in AOSE; (iii) describe a traceability frame- The requirements specification approach described in this paper work with supporting tool; (iv) present a feature-based comparison via User and System Stories is intended to complement the existing of USS to other approaches; and (v) provide a proof-of-concept AOSE methodologies rather than replace any of them. For the pur- evaluation of the above mentioned hypotheses with users from our pose of grounding our work we chose the TDF methodology as it current industry collaborations. is used in the industry project that motivates this work. TDF [15, 16] is the successor to Prometheus [25], a mature and 2 BACKGROUND popular AOSE methodology. A pilot study has shown that TDF sig- In this section we introduce the preliminaries in terms of User nificantly improves comprehension of behaviour models, compared Stories and acceptance criteria as used in agile approaches, and a to UML [18]. The methodology follows 3 phases in an iterative brief overview of TDF and SARL. manner: System specification where the system-level artifacts are identified, namely goals, scenarios, percepts, actions, data, actors 2.1 Agile & User Stories and roles; System architecture where the internals of the system are specified, namely the agents that enact the different rolesand Agile approaches finds their roots in the movement started by the the interactions between them; and Detailed design that defines the Agile Manifesto [2] that defines its core values and principles. A internals of the agents, namely plan diagrams, tactics and internal number of software development life cycles (SDLC) have embraced messages/sub-goals. the fundamental principles, e.g. Scrum [30] and Extreme Program- There are several agent implementation frameworks that support ming [1]. A key value of agile approaches is the close collaboration the implementation of intelligent agent systems, e.g. JACK [34], of the development team with stakeholders. Agile methods always SARL [29], Jadex [28], and Jason [3]. We use SARL in our work, favor and encourage conversations to develop a shared understand- since it is what is currently used in our industry project and the TDF ing over rigid requirement specification documents. A number of design artifacts are readily implemented in SARL (recent work [18] techniques have been proposed to understand the objectives and ex- also used this combination). pectations of the stakeholders (e.g User Interviews, Questionnaires, SARL is a general-purpose agent-oriented system implemen- Story-Writing workshops) [8]. In this context, the most common tation framework that provides the fundamental abstractions to technique to gather and document requirements in agile frame- develop and deploy distributed complex systems. Due to its generic works are User Stories [1]: a brief informal description of a feature and highly extensible architecture, SARL is able to integrate new described from the perspective of a user of the system. concepts and features quickly and has been adopted by a number Writing good User Stories and capturing sufficient detail is still of academic and industrial institutions to develop a wide range of a matter of debate and often requires specialized training. However, applications. Space preclude a more detailed introduction to SARL, there is a general agreement that stories should remain high level which is not required for this paper. For further details see [29]. in the early stages [8, 9]. They are then refined and detailed as they get a higher priority in the project development. 3 APPROACH While there is no single format of User Stories, the most widely In this section we describe our approach to specifying the require- used template is: As (role), I want to (do something), so that (reason). ments of the system via User and System Stories and how they For example, for a bookstore system: As a customer, I want to search translate to agent concepts, resulting in all of the benefits described for books by keywords, so that I can find the book I want.
Load more

Recommended publications
  • Rugby - a Process Model for Continuous Software Engineering
    INSTITUT FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rugby - A Process Model for Continuous Software Engineering Stephan Tobias Krusche Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Universitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Helmut Seidl Prufer¨ der Dissertation: 1. Univ.-Prof. Bernd Brugge,¨ Ph.D. 2. Prof. Dr. Jurgen¨ Borstler,¨ Blekinge Institute of Technology, Karlskrona, Schweden Die Dissertation wurde am 28.01.2016 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 29.02.2016 angenommen. Abstract Software is developed in increasingly dynamic environments. Organizations need the capability to deal with uncertainty and to react to unexpected changes in require- ments and technologies. Agile methods already improve the flexibility towards changes and with the emergence of continuous delivery, regular feedback loops have become possible. The abilities to maintain high code quality through reviews, to regularly re- lease software, and to collect and prioritize user feedback, are necessary for con- tinuous software engineering. However, there exists no uniform process model that handles the increasing number of reviews, releases and feedback reports. In this dissertation, we describe Rugby, a process model for continuous software en- gineering that is based on a meta model, which treats development activities as parallel workflows and which allows tailoring, customization and extension. Rugby includes a change model and treats changes as events that activate workflows. It integrates re- view management, release management, and feedback management as workflows. As a consequence, Rugby handles the increasing number of reviews, releases and feedback and at the same time decreases their size and effort.
    [Show full text]
  • Agile Playbook V2.1—What’S New?
    AGILE P L AY B O OK TABLE OF CONTENTS INTRODUCTION ..........................................................................................................4 Who should use this playbook? ................................................................................6 How should you use this playbook? .........................................................................6 Agile Playbook v2.1—What’s new? ...........................................................................6 How and where can you contribute to this playbook?.............................................7 MEET YOUR GUIDES ...................................................................................................8 AN AGILE DELIVERY MODEL ....................................................................................10 GETTING STARTED.....................................................................................................12 THE PLAYS ...................................................................................................................14 Delivery ......................................................................................................................15 Play: Start with Scrum ...........................................................................................15 Play: Seeing success but need more fexibility? Move on to Scrumban ............17 Play: If you are ready to kick of the training wheels, try Kanban .......................18 Value ......................................................................................................................19
    [Show full text]
  • Managing Defects in an Agile Environment
    Managing Defects in an Agile environment Auteur Ron Eringa Managing Defects in an Agile environment Introduction Injecting passion, Agility Teams often struggle with answering the following and quality into your question: “How to manage our Defects in an organisation. Agile environment?”. They start using Scrum as a framework for developing their software and while implementing, they experience trouble on how to deal with the Defects they find/cause along the way. Scrum is a framework that does not explicitly tell you how to handle Defects. The strait forward answer is to treat your Defects as Product Backlog Items that should be added to the Product Backlog. When the priority is set high enough by the Product Owner, they will be picked up by the Development Team in the next Sprint. The application of this is a little bit more difficult and hence should be explained in more detail. RON ERINGA 1. What is a defect? AGILE COACH Wikipedia: “A software bug (or defect) is an error, flaw, After being graduated from the Fontys failure, or fault in a computer program or system that University in Eindhoven, I worked as a Software produces an incorrect or unexpected result, or causes Engineer/Designer for ten years. Although I it to behave in unintended ways. Most bugs arise have always enjoyed technics, helping people from mistakes and errors made by people in either a and organizations are my passion. Especially program’s source code or its design, or in frameworks to deliver better quality together. When people and operating systems used by such programs, and focus towards a common goal, interaction is a few are caused by compilers producing incorrect increasing and energy is released.
    [Show full text]
  • Towards a Discipline for Agile Requirements
    Forging High-Quality User Stories: Towards a Discipline for Agile Requirements Garm Lucassen, Fabiano Dalpiaz, Jan Martijn E.M. van der Werf and Sjaak Brinkkemper Department of Information and Computing Sciences Utrecht University Email: g.lucassen, f.dalpiaz, j.m.e.m.vanderwerf, s.brinkkemper @uu.nl { } Abstract—User stories are a widely used notation for formulat- which will remain impossible to achieve in the foreseeable ing requirements in agile development. Despite their popularity in future [11]. industry, little to no academic work is available on determining Instead, tools that want to harness NLP are effective only their quality. The few existing approaches are too generic or employ highly qualitative metrics. We propose the Quality User when they focus on the clerical part of RE that a tool can Story Framework, consisting of 14 quality criteria that user perform with 100% recall and high precision, leaving thinking- stories should strive to conform to. Additionally, we introduce required work to human requirements engineers [6]. Addition- the conceptual model of a user story, which we rely on to ally, they should conform to what practitioners actually do, subsequently design the AQUSA tool. This conceptual piece of instead of what the published methods and processes advise software aids requirements engineers in turning raw user stories into higher quality ones by exposing defects and deviations from them to do [12]. User stories’ popularity among practitioners good practice in user stories. We evaluate our work by applying and simple yet strict structure make them ideal candidates. the framework and a prototype implementation to multiple case Throughout the remainder of this paper we make five studies.
    [Show full text]
  • Agile Testing Practices
    Agile Testing Practices Megan S. Sumrell Director of Transformation Services Valtech Introductions About us… Now about you… Your name Your company Your role Your experience with Agile or Scrum? Personal Expectations Agenda Introductions Agile Overview Traditional QA Teams Traditional Automation Approaches Role of an Agile Tester Testing Activities Refine Acceptance Criteria TDD Manual / Exploratory Testing Defect Management Documentation Performance Testing Regression Testing Agenda Continued Test Automation on Agile Teams Testing on a Greenfield Project Testing on a Legacy Application Estimation Sessions Sprint Planning Meetings Retrospectives Infrastructure Skills and Titles Closing Agile Overview Agile Manifesto "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." Scrum Terms and Definitions User Story: high level requirements Product Backlog: list of prioritized user stories Sprint : one cycle or iteration (usually 2 or 4 weeks in length) Daily Stand-up: 15 minute meeting every day to review status Scrum Master: owns the Scrum process and removes impediments Product Owner: focused on ROI and owns priorities on the backlog Pigs and Chickens Traditional QA Teams How are you organized? When do you get involved in the project? What does your “test phase” look like? What testing challenges do you have? Traditional Test Automation Automation Challenges Cost of tools Hard to learn Can’t find time Maintenance UI dependent Only a few people can run them Traditional Test Pyramid UNIT TESTS Business Rules GUI TESTS Will these strategies work in an Agile environment? Food for Thought…….
    [Show full text]
  • LEVERAGING USER STORIES in AGILE TRANSFORMATION a Value-Driven Approach to Documenting Requirements for Agile Teams
    LEVERAGING USER STORIES IN AGILE TRANSFORMATION A Value-Driven Approach to Documenting Requirements for Agile Teams Meagan Foster Data & Analytics Intern, IQVIA, Inc. Summer 2020 INTERNSHIP PROJECTS + Connected Devices Project . Requirements development and management for module titles and user interface access . Document an end-to-end diagram for Connected Devices + Clinical Data Repository Tabular Project . Requirements development and management to enable CDR support for password protected SAS and excel-based files + Process Improvement Project . Best practices in creating user stories . “1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Agile Manifesto PRESENTATION OVERVIEW + Agile Philosophy on Customer Value + Documenting Customer Value with User Stories + Reinforcing Customer Value with Quality Attributes + Navigating Customer Value with the Inspect-Adapt Approach PRESENTATION OVERVIEW + Agile Philosophy on Customer Value + Documenting Customer Value with User Stories + Reinforcing Customer Value with Quality Attributes + Navigating Customer Value with the Inspect-Adapt Approach AGILE TRANSFORMATION • Capterra states that 71% of companies are implementing Agile. • VersionOne reveals that Agile adoption has helped out 98% of companies. • Harvard Business Review declares that 60% of companies experience revenue growth and profits increase after using an Agile approach. • Standish Group Chaos Study reports that Agile success rate is 42%, as compared to Waterfall success rate of 26%. This means Agile is 1.5x more successful than Waterfall model. AGILE IS WAY OF THINKING. • Not everything needs to be figured out Fixed right away. Quality • Get feedback early and often. Estimate • Anticipate and quickly adapt to change. • Focus on bringing value to customers. THE PRODUCT BACKLOG (SCRUM) Implementable items to build features Features planned for delivery Vision, strategy, and ideas for new features and tools FIGURE 1.
    [Show full text]
  • User Stories.Book
    User Stories Applied for Agile Software Development Mike Cohn Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Chapter 2 Writing Stories In this chapter we turn our attention to writing the stories. To create good sto- ries we focus on six attributes. A good story is: • Independent • Negotiable • Valuable to users or customers •Estimatable •Small •Testable Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, has suggested the acronym INVEST for these six attributes (Wake 2003a). Independent As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and plan- ning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority. Dependencies between stories can also make estimation much harder than it needs to be. For example, suppose we are working on the BigMoneyJobs website and need to write stories for how companies can pay for the job openings they post to our site. We could write these stories: 1. A company can pay for a job posting with a Visa card. 2. A company can pay for a job posting with a MasterCard. 17 18 WRITING STORIES 3. A company can pay for a job posting with an American Express card. Suppose the developers estimate that it will take three days to support the first credit card type (regardless of which it is) and then one day each for the second and third.
    [Show full text]
  • User-Stories-Applied-Mike-Cohn.Pdf
    ptg User Stories Applied ptg From the Library of www.wowebook.com The Addison-Wesley Signature Series The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advi- sors, world-class authors in their own right. These experts are proud to put their signatures on the cov- ers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbol- ize a promise to our readers: you are reading a future classic. The Addison-Wesley Signature Series Signers: Kent Beck and Martin Fowler Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good — finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical con- straints. His books focus on touching the lives of the creators and users of software. Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, ptg practices, and principles that last for many years; these books should be usable a decade from now.
    [Show full text]
  • Selecting a Development Process: Choosing Among the Leading Alternatives Mike Cohn Mountain Goat Software [email protected]
    Selecting a Development Process: Choosing Among the Leading Alternatives Mike Cohn Mountain Goat Software [email protected] Copyright Mountain Goat Software, LLC 1 Mike Cohn - background Copyright Mountain Goat Software, LLC 2 Today’s agenda Considerations Team Software Proce ss Scrum Extreme Programming OpenUP/Basic Rational Unified Process Copyright Mountain Goat Software, LLC 3 Ceremony • The amount of formalism in a process • Documentation, method weight, reviews Few documents Many documents Few steps Formal steps Copyright Mountain Goat Software, LLC 4 Cycles Sequential • Number and length of iterations Few documents Many documents Few steps Formal steps Many short iterations (5 days) Copyright Mountain Goat Software, LLC 5 Placing the processes Sequential Few documents Many documents Few steps Formal steps Many short iterations (5 days) Copyright Mountain Goat Software, LLC 6 Today’s agenda Considerations Team Software Proce ss Scrum Extreme Programming OpenUP/Basic Rational Unified Process Copyright Mountain Goat Software, LLC 7 Team Software Process (TSP) • Created by Watts Humphrey • Of Software Engineering Institute and Capability Maturity Model (CMM) • Builds on his Personal Software Process • High discipline, highly defined • A “cyclic development strategy” • Another way of saying “iterative and incremental” Copyright Mountain Goat Software, LLC 8 Goals of the TSP 1. Build on the Personal Software Process 2. Develop products in cycles 3. Establish standard measures for quality and performance 4. Provide precise measures
    [Show full text]
  • Use Cases, User Stories and Bizdevops
    Use Cases, User Stories and BizDevOps Peter Forbrig University of Rostock, Chair in Software Engineering, Albert-Einstein-Str. 22, 18055 Rostock [email protected] Abstract. DevOps is currently discussed a lot in computer science communi- ties. BizDev (business development) is only mentioned once in a computer sci- ence paper in connection with Continuous Software Engineering. Otherwise it is used in the domain of business administration only. Additionally, there seems to be a different interpretation of the term in the two communities. The paper discusses the different interpretations found in the literature. Addi- tionally, the idea of BizDevOps is discussed in conjunction with further ideas of taking new requirements for software features into account. These requirements can be described by models on different level of granularity. Starting points are use cases, use-case slices, user stories, and scenarios. They have to be commu- nicated between stakeholders. It is argued in this paper that storytelling can be a solution for that. It is used in as well in software development as in manage- ment. Keywords: BizDev, DevOps, BizDevOps, Continuous Requirements Engineer- ing, Continuous Software Engineering, Agile Software Development, Storytell- ing. 1 Introduction Developing Businesses if often related with the development of software because nowadays business processes have to be supported by IT. Continuous requirements engineering has to be performed to provide continuously the optimal support. Contin- uous business development seems to be a good description for the combined devel- opment of software and business. This term is not used so very often. Nevertheless, it exists like in [17]. However, more often the abbreviation BizDev (business development) is used.
    [Show full text]
  • San José State University Computer Science Department CS160, Software Engineering, Section 4, Spring 2018
    San José State University Computer Science Department CS160, Software Engineering, Section 4, Spring 2018 Course and Contact Information Instructor: Fain (Frank) Butt Office Location: MH212 Telephone: (408) 924-5060 Email: [email protected] Office Hours: TR 8:45 PM – 10:00 PM (by appointment) Class Days/Time: Section 4: TR 7:30 - 8:45 PM Classroom: MH222 Prerequisites: Prerequisite: CS 146, CS 151 (with a grade of "C-" or better in each); CS 100W (with a grade of "C" or better) Course Format All your programming project deliverable must be able to compile and run before packaging for submission. Otherwise you will not earn many points if we can’t verify your results. You are expected to spend 15-20 hours a week on homework and/or project. Faculty Web Page and MYSJSU Messaging Course syllabus and the rest of the course information will be published via Canvas. You are responsible for regularly checking with the messaging system through MySJSU and Canvas to learn of any updates. Course Description Software engineering principles, requirements elicitation and analysis, design, configuration management, quality control, project planning, social and ethical issues. Required team-based software development, including written requirements specification and design documentation, oral presentation, and tool use. Course Learning Outcomes (CLO) Upon successful completion of this course, students will be able to: 1. CLO 1 – Design and build a project from end to end 2. CLO 2 – Write a Requirement Document 3. CLO 3 – Write High-level and low-level designs 4. CLO 4 – Iterative Implementation 5. CLO 5 – Understanding Different Stages of Quality Assurance 6.
    [Show full text]
  • User Stories – the Art of Writing Agile Requirements
    User Stories – The Art of Writing Agile Requirements Speakers: Susana Esparza & Raj Indugula Company: LitheSpeed Website: lithespeed.com Welcome to the PMI Houston Conference & Expo and Annual Job Fair 2014 • Please set your cell phone to silent mode • There will be time at the end of this presentation for you to take a few moments to complete the session survey. We value your feedback which allows us to improve this annual event. 1 Agenda for Today’s Workshop • Introduction • Overview of Agile/Scrum • From Vision to Acceptance Criteria ¡ Modeling Users & Customers ¡ Epics, Features & User Stories ¡ Elaborating from Vision to Story ¡ Acceptance Criteria & Testable Examples • Q & A 2 An Introductory Exercise 1. Find a partner. 2. Start telling them about yourself. 3. When they hear something you both have in common, they will say “Me Too!” and find a new partner. 3 Problem Context: Communication Business Development Wants Builds QA Tests 4 Striking a Balance Business Development 5 Overview Agile & Scrum The Agile Landscape “Agile” describes a number of related methods. Scrum is the most popular. Scrum • Scrum Scrum / XP Jeff Sutherland & Ken Schwaber • Extreme Programming (XP) Kent Beck, Ward Cunningham, Ron Jeffries • Kanban David Anderson • Scaled Agile Framework (SAFe) Source: 2010 State of Agile Dean Leffingwell Development Survey, VersionOne 7 Dealing with Uncertainty You don’t need agile if you know what to build, who to build it for, and how to build it Initial Plan Empirical methods Use agile when monitor progress & you have uncertainty…
    [Show full text]