OIA Live and Learn – Agile Orientation Brief

1. OIA Live and Learn – Agile Orientation Brief Health System Portfolio Management/Strategic Investment Management Agile Workgroup Emily Jevec, Integrated Electronic Health Record (iEHR) Requirements Analyst Lead Requirements Development and Management (RDM) Andrew G. Knaster Senior Information Analyst/Modeler Interagency Architectural Collaboration (IAC) Strategic Investment Management (SIM) Office of Informatics and Analytics (OIA) June 2013

2. Agenda • Background • Purpose • Definition of Terms • New Service Request (NSR) Process Changes • Deliverable Revisions • Pilots • Tooling Recommendations • Training Recommendations

3. Background • Office of Information Technology (OIT) Product Development is transitioning to the use of agile/lean development methodologies • Business Owners and Business Stakeholders will be significantly impacted by the change. The business will assume more responsibility and accountability for directing the outcome of products under development. • Health Systems Portfolio Management (HSPM) and Strategic Investment Management (SIM) will be influenced by agile/lean requirements development methodology ; practices and processes need to be evaluated and revised, as appropriate ,to ensure adequate support of projects. • The HSPM/SIM Agile Working Group (AWG) has been established to enable best practices within the Directorate to support agile/lean practices.

4. Purpose • The purpose of the Agile Work Group is to enable Health Systems Portfolio Management (HSPM) /Strategic Investment Management (SIM) staff to leverage agile/lean methodologies with Business Owners and Business Stakeholders to collaborate effectively and efficiently with Office of Information Technology (OIT) project teams through the following activities: • Educating and informing HSPM/SIM staff and thereby, Business Owners and Business Stakeholders regarding agile/lean methodologies • Adapting current Health Systems documentation artifacts to support agile/lean development efforts • Identification of training materials to assist Business Owners and Business Stakeholders in understanding their roles and responsibilities related to agile/lean methodologies

5. Definition of Agile • Agile is an approach to software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self organizing, cross functional teams. • Agile delivery requires continuous planning across the lifecycle of the program and its component products, allowing business critical products and features to be delivered based on priority.

6. Definition of Terms The following terms will help you to understand the new business process: • Epics: A large user story that can be broken down into several user stories. • Example: As a clinician I need to be able to manage outpatient prescription/medication orders in order to maximize patient care. • User Stories: Single-sentence statement that describes the desired functionality from the perspective of the user. The user story utilizes the following format:As <user role>, I want <activity> so that <business value>. • As a clinician I want to be able to write a medication order so that the pharmacy can dispense the appropriate medication to the patient. • Sub-Stories: A further decomposition of a user story. • As a physician, I want to be able to write a prescription for a narcotic so that the pharmacy can dispense the appropriate medication to the patient. • As nurse practitioner, I want to be able to write a prescription for non-narcotic medications so that the pharmacy can dispense the appropriate medication to the patient.

7. Terminology Continued • Acceptance Criteria: Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. • Requirements Traceability Matrix (RTM): An artifact used to document epics, user stories, acceptance criteria, requirements priority and mappings to models. • Business Requirements Document (BRD): A document written to define the scope and requirements of a business process or a system that needs to support a business process. • Requirements Elaboration Document (RED): A further decomposition of business requirements. It includes user stories, acceptance criteria, and sub-stories

8. New Service Request (NSR) Process Changes: Phase One Phase One: NSR Analysis • Requirements Development and Management (RDM) Analyst will reach out to Office of Information Technology (OIT) to see if resources are available to attend analysis meetings • RDM Analyst will facilitate analysis meetings with Subject Matter Experts (SMEs) • RDM Analyst will document epics and features in the form of user stories in the Requirements Traceability Matrix (RTM) template. All other information will be documented in the Business Requirements Document (BRD) • RDM Analysts will document acceptance criteria if that information is received during user story definition • RTM and BRD will be saved in the New Service Request Database (NSRD)

9. New Service Request (NSR) Process Changes: Phase Two Phase Two: NSR Elaboration • Requirements Development and Management (RDM) Analyst will reach out to Office of Information Technology (OIT) to see if resources are available to attend analysis meetings or if current OIT resources will continue to participate in analysis • RDM Analyst will build upon user stories to define the acceptance criteria and sub-stories. This information will be documented in a Requirements Elaboration Document (RED) • Analyst will build upon the Requirements Traceability Matrix (RTM)

10. Deliverable Revisions: Phase One • Recommended changes to the Business Requirements Document (BRD): • Include agile introductory text prior to the user story table • Include epic definitions prior to the user story table • Replace the traditional requirements table with a link to the New Service Request Database (NSRD) • Capture and prioritize epic/user story/acceptance criteria • Map user stories to the process model steps

11. Deliverable Revisions: Phase Two • Recommended changes to the Requirements Elaboration Document (RED): • Refine user stories, define acceptance criteria, tasks or sub-stories • Continue to map user stories to process model steps

12. Pilots • The proposed process, updated Business Requirements Document (BRD) and Requirements Traceability Matrix (RTM) , is currently being piloted with Mobile Applications requirements efforts. • Additional potential pilots are: • Virtual Lifetime Electronic Record (VLER) • Agile Lean Implementation Work Group (ALIWG) members may be able to provide recommendations for a pilot

13. Tooling Recommendation • To effectively employ agile processes, the Requirements Development and Management (RDM) team will use IBM Rational Requirements Composer (RRC) to capture epics, user stories, and acceptance criteria. • RRC integrates Rational Team Concert (RTC), used by the development teams; RTC assists with traceability and change management.

14. Training Recommendations • Talent Management System (TMS) Courses recommended for Requirements Analysts: • An Overview of Agile Methodologies • Agile Planning: Project Initiating and Requirements Gathering • Managing Stakeholder Engagement on an Agile Project • TMS Continuing Education Courses: • Agile Project Management Essentials • Agile Planning: Doing Estimates and Completing the Release Plan • Agile Programming and Testing • Ensuring Delivery of Value and Quality in Agile Projects • Leading an Agile Team • Managing Agile Software Development • Adopting an Agile Approach to Project Management • Overview of the Scrum Development Process • Planning an Agile Software Development Project • Planning and Monitoring Iterations on an Agile Project

15. Questions? • Additional Links: • Agile Workgroup • Resources and References • Agile training Courses Available for Limited Timeframe