1. BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting July 14, 2011 08-2011 Interactive Solutions Delivery Methodology What it means for Business Consultants

2. Agile & Scrum: What do the terms really mean? “Agile Software Development is a group of software development methodologies based iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.” 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 is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.” Taken from the sport of Rugby, “Scrum is a maneuver where “the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) ‘tries to go the distance as a unit, passing the ball back and forth’.” Agile Manifesto

3. ISDM: Interactive Solutions Delivery Methodology EIM’s Interactive Solutions Delivery Methodology (ISDM) is an end-to-end, project management methodology applicable to the provisioning of customer-driven software & hardware solutions. ISDM uses Agile concepts, and provides guidelines for the initiation and establishment of a project, the initial definition and design of the solution, the iterative build and delivery process that directs value-driven solution implementation, and the ultimate delivery and closure of a project. ISDM requires each project to have a triad of leadership… each area having a representative involved in the project from beginning to end. While the delivery frameworks within ISDM are iterative (Scrums), time itself is linear, and there are linear milestones that need to be met to move a project through from beginning to end.

4. ISDM High Level Process As part of the Business Consultant group, it is important that we are involved minimally as early as Project Establishment. In each step, different activities are occurring, and specific deliverables will be generated. There may be some variation from project to project, but the goal is to have a high degree of predictability from project to project as to what deliverables are standard. At each gate, deliverables and activities for a step need to be “Done Enough” as determined by the project charter and contract before the project moves into the next step.

5. Scrum within ISDM Scrum is an iterative framework for executing against a project that defines and requires team members to work together, each performing their role in a synergistic atmosphere. Scrum frameworks are characterized by well defined, team-centric meetings and activities. The frameworks can work with any phase or sprint, not just software development sprints. Sprint Cycles – a series of short phases or releases cycles Daily Scrum Meetings (including customer interaction) Scrum of Scrum Meetings (less frequent) Sprint Planning Meetings (or step planning – prioritizing and committing to work items that need to get done) Tracking of Progress against tasks (burn-down) “End of Sprint Demo” for Build Sprints Retrospective (lessons learned) Frameworks that define how work gets done… Repeat…

6. ISDM High Level Process In the Establish step, EIM seeks a firm understanding and documentation of the high-level goals and value metrics of the client in order to create a draft project plan, project charter, and all associated artifacts to be delivered to the client. The charter will help determine what “Done Enough” means across the project (agile/waterfall continuum definition and impacts). Establish Contract Initiation Checklist Project Charter Preliminary Schedule Cost Proposal High Level Solution Description Possibly another deliverable, TBD The Business Consultant team will be involved in early discussions with the customer (along with the PM and Tech Lead/Architect), and help minimally define the solution at a very high level (no details). Most likely this is done by a person playing the Product Owner or Solution Architect role. By bringing the BA team in at this level, early estimates will be more accurate. Activities & Deliverables

7. ISDM High Level Process Define In the Define step, all project requirements, including risks and milestones to be tracked during delivery, are defined. In this step, both the project and the solution are being defined iteratively and collaboratively. Amount of detail defined is determined by the “Done Enough” definition in the project charter (and agreement of all stakeholders). Project Schedule with Deliverables Project Management Plan HW and SW Build Plan QA Approach Training Approach & Transition Approach 2-Layer Solution Description Draft Raw Requirements (Delivery TBD*) The Business Consultant team will be key players in this step, iteratively collecting/reviewing requirements, synthesizing them and working through the UX solution. This may be 1 or more people playing roles of BA, Product Owner, Solution Architect and possibly a UI Designer (although UI Mocks won’t be expected until the Design step). See the Requirements Gathering training module for details of those activities. Activities & Deliverables *We are currently working through guidelines for the raw requirements doc versus a System Requirements Spec, with a goal of pushing a customer commitment to the System Requirements Spec stage. User Login

8. ISDM High Level Process Design In the Design step, solution features that were identified during the Define step are decomposed into more detailed requirements, then synthesized into a system design at both the User Interaction (UX) level and the underlying technology level. The Design Step produces clarity in what is being built and how it will be built to some degree. Technical Architecture System Management Plan Organizational Communication Plan Prelim Training, Transition & QA Plans Prioritized Feature Backlog (User Stories) Complete SDD UI Mocks System Requirements Specification The Business Consultant team will be key players in this step, iteratively collecting/reviewing requirements, synthesizing them and working through the UX solution. This may be 1 or more people playing roles of BA, Product Owner, Solution Architect and possibly a UI Designer (although UI Mocks won’t be expected until the Design step). See the Requirements Gathering training module for details of those activities. Activities & Deliverables

9. ISDM High Level Process Build In the Build step, EIM will begin to build the architected solution in an iterative define-design- build-assess-release mini-release cycle. A unique training module will be devoted to the construction of a Build Sprint since the huge majority of time on any project is spent in the Build Step. Detailed Design Specification As Built Documentation if Required QA Plan Release Plan Draft Transition Plan Additional User Stories for Future Backlog Training Templates User Documentation Drafts The BA, Product Owner, Trainer & Writer will be involved during Build sprints. The Product Owner prioritizes both the product and sprint backlogs (working a sprint ahead), and selects the User Stories to be addressed with each Sprint in conjunction with the customer. As the voice of (and liaison to) the customer, the Product Owner holds many clarifying conversations with development and test, and ensures accurate acceptance criteria exists. Other BAs continue to collect and record requirements/User Stories to feed the backlog as necessary. The trainer and Writer begin preparing drafts. Activities & Deliverables

10. ISDM High Level Process Assess In the Assess step, EIM will execute the final regression testing and User Acceptance testing that must be run against the complete system for customer sign-off. Because there is testing that occurs during each Build Step, the Assess Step in ISDM is much shorter than in more traditional projects. System Acceptance Documentation Defect Tracking Reports Deployment Plans Operational Plans Business Continuity Plans Training Drafts User Documentation Drafts The Business Consultant team will play both a consultative role and active role during Assess, with the BAs and Product Owner clarifying any questions raised by testers re: acceptance criteria and the Writers and Trainers completing their documentation and curriculum. Additionally, UI Designers may need to make last minute updates against any relevant defects or critical usability issues. Activities & Deliverables

11. ISDM High Level Process Release In the Release step, EIM will move towards the final action of closing out a project. System acceptance documentation, defect tracking reports, deployment and operation plans and a continuity plan will all be turned over to the client prior to Release, as will any user documentation and training materials. Release Notes System Acceptance Operational Impact Assessment Reference Approval and SLA Lessons Learned Final User Documentation Final Training & Documentation Follow-on Backlog (complete) Activities & Deliverables The Business Consultant team will mostly be represented in this step by Training and Documentation, with training likely occurring near the project close date and final documentation deliveries following a similar pattern. Until the project closes, there may be additions to the Follow-on Backlog which need to be managed by the BA and/or Product Owner. If a traceability matrix was required, it likely will also be delivered in this step.

12. Key points to remember… Summary Our team is involved in every step of a project after it is originated. We get our work done in each step using Scrum frameworks, which are well defined, team-centric iterative guidelines. While ISDM borrows from many Agile principles (including the use of Scrum frameworks), the methodology can accommodate projects with waterfall contractual obligations – the main difference is in the definition of “Done Enough” in the early steps and in the handling of ongoing requirements gathering (change requests) sprint to sprint. ISDM provides frameworks and guidelines that are flexible – allowing the PM to nail down non-negotiables in the Project Charter. ISDM and Business Consultants