Agile Resources Series 2

Transcription

1 Table of Contents Purpose... 3 Criteria for Using Agile Development Techniques Agile Overview Definition of Agile Development Benefits of Agile Development Roles and Responsibilities Scrum Master Product Owner Agile Coach Delivery Manager Manager Existing Project Roles Mapping Agile Development to Traditional Software Development... 6 Pre Sprint 0 Project Set-up Sprint Sprints 1 n Guidelines for Managing Agile Development Efforts Project Set Up General Project Deliverables List (PDL)... Error! Bookmark not defined Planning Considerations Sprint Backlog Documentation Forecasting Business... Error! Bookmark not defined. 2.4 Requirements Traceability Environment Architecture Application Architect - SAD Information Architecture (IA) Testing Sprint Level Testing Release Level Testing Regression Testing System Testing Specialty Testing User Acceptance Testing Automation Testing Testing Documentation Defect Tracking ERM (Enterprise Release Management)... 21

2 2.10 Infrastructure Infrastructure Checklist for new Agile Project Startup Gates & Reviews WPR of Planning Deliverables Sprint Demo Sprint Retrospective Enterprise Architecture Governance (EAG) Reviews Finance and Velocity Exit Gate Finance and Velocity Exit Gate Summary Sprint Progress Gates Configuration Management Change Management Quality Management Transition / P&E Support Warranty Period Function Points Partner Satisfaction Survey Appendix A Terminology of Agile Development Appendix B Meetings specific to Agile Appendix C Agile Project Dashboard Revision History... 34

3 Purpose This handbook provides guidance on planning, managing, and executing a project using Agile techniques within the Agile framework. Teams not following Agile Outlook s Agile techniques will need to tailor artifacts that are done in a different manner, and waive artifacts that are deemed not applicable. This Handbook provides a framework, but each projects will have to incorporate additional tailoring and waiving for their particular situations. This handbook does not give specific guidance to IT Maintenance and Service Desk team. Criteria for Using Agile Development Techniques Projects must be approved through the Agile Demand Management process as defined by Agile Outlook for this organization. Before using Agile techniques, including this Handbook. If you need additional information about the Demand Management and Project approval process in Agile, consultants from Agile Outlook can be contacted at info@agileoutlook.com Information about the project vetting process is also available in the Demand Management Guide from Agile Outlook Review the Agile Project Expectations to understand the commitment and requirements necessary for Agile projects. 1. Agile Overview 1.1 Definition of Agile Development Agile software development refers to a group of software development methodologies based on iterative development and frequent incremental delivery. In Agile projects, requirements and solutions evolve through collaboration between the Product Owner and self-organizing cross-functional teams. See Appendix A for definitions of Agile development terminology. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile methods produce completely designed, developed, and tested features (a small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, receiving feedback from the Product Owner and Business Stakeholders and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point before delivery, there is no tangible business value produced. With the agile method, being cancelled at any point will still leave the customer with the highest priority requirements tested, working, and accepted, that can begin delivering benefits to users.

4 Agile methods are similar to other iterative and incremental development methods, as the emphasis is on delivering potentially shippable software every short cycle (1-4 weeks). Agile development differs as the duration are measured in weeks rather than months, and work is performed in a highly collaborative manner. Agile allows for continuous requirements discovery within each iteration (or sprint). Subsequent timeboxes/iterations cycle through Design, Development, Testing and Implementation for chunks of requirements. 1.2 Benefits of Agile Development Resolves or mitigates major risks before making large investments in budget dollars Improved quality of the (end) product due to user s ability to provide feedback on the solution incrementally during each iteration Architecturally significant items are addressed early and validated through each iteration Enables component based development. Highest value elements are delivered first and can accelerate ROI (Return on Investment) Projects are more resilient (and cheaper) to change, so adaptation to change can become a competitive advantage Accelerates learning and requirements gathering in projects with uncertain or rapidly changing requirements 1.3 Roles and Responsibilities This section outlines additional responsibilities that some roles within the current methodology must take on to support Agile Development Scrum Master The role of the Scrum Master can be filled by any of a number of roles, depending upon the nature of the project. Scrum Master should attend training before beginning their first Agile project. Facilitates sprint planning Facilitates the Daily Scrum meeting

5 Facilitates the Scrum process; doesn t tell team what to do Facilitates Retrospective meeting at the end of each sprint Facilitates Sprint Demo (demonstration) with all stakeholders Maintains sprint burn down and release burn down/burn up if team is using this charting method Supports Release planning release plan and projections on backlog are scope reporting items Helps Product Owner with backlog grooming Facilitates Product Owner acceptance of work (ongoing) Takes responsibility for clearing impediments that team can t solve themselves Is responsible for guarding and reinforcing the process and working toward continuous improvement Product Owner The Product Owner is the broker of all business stakeholders and interests and is the single voice representing all business stakeholders to the Team. The Product Owner may be filled by a Business SME for traditional projects, or it may be filled by a technical resource in the case of an Infrastructure project. The Product Owner is an integral part of the Agile team, and must be heavily involved; this role should be a dedicated resource. The Product Owner needs to work with the team daily to ensure that the top priority stories are addressed. Develops/defines product Vision and Roadmap Defines and maintains the Product Backlog Prioritizes all features in Product Backlog based on business value Defines acceptance criteria for features/stories Accepts or rejects completed stories (features/functions) Performs ongoing product backlog grooming in collaboration with the core team (BA, QA, Architect, and Scrum Master) Collaborates with the Release Manager to define- release plan Defines product roadmap Defines product vision Agile Coach A dedicated Agile Coach is key to the success of a project. The Agile Coach will work with the team on a daily basis to help the team learn and understand the Agile practices. An Agile Coach should be assigned to the project as soon as it is approved through the vetting process. The level of involvement of the coach will be determined by the experience of the team; for example, a project team that has successfully implemented a project using Agile practices may require less coaching than a new team. This coach will focus on the Agile Process. There may also be a need for a Technical Coach if the organization is interested to integrate DevOps with Agile. P.S: Agile Outlook can be contacted if your organization has need for any Agile Resources Delivery Manager This role is a crucial part of an Agile project, and is separate from the Scrum Master and Product Owner. Delivery Managers are responsible for managing the project and project deliverables in the same way as a traditional waterfall project.

6 1.3.5 Existing Project Roles Along with these Agile-specific roles, traditional roles continue as usual. Application Architects, Information Architects, Infrastructure Leads, etc. are assigned to support the Agile project as needed. Some roles, like Business Analysts, Developers and Testers, will be assigned full time and will be a part of each Sprint while some other roles, like Information Architects, Application Architects, DBAs, will be brought in when Sprint content requires their support. 1.4 Mapping Existing Projects to Agile Development In general, the Ideation phase proceeds as it does for a waterfall project. Phases 4 and 5 (Design and Development) will change due to the use of iterative sprints. Phase 5 Testing, Phases 6 and 7 will have some changes to accommodate items unique to Agile. Teams following Agile practices will need to tailor artifacts that are done in a different manner, and waive artifacts that are deemed not applicable. This Handbook provides a framework, but individual projects will have to incorporate additional tailoring and waiving for their particular situations. Planning is a crucial part of any project, and Agile projects place even more emphasis on planning. Teams should fully document project-planning activities, using the Agile Outlook s and other templates as applicable. Pre Sprint 0 Project Set-up At project start-up the Project Manager identifies key stakeholders. For Agile development it is important to identify Product Owner(s) and core technical resources based on the impacted domain(s) and/or application(s). It is also critical to engage the Infrastructure group to let them know that an Agile project is beginning. Prior to Sprint 0, the Infrastructure Manager sets up an initial infrastructure requirements gathering meeting (30 minutes). Meeting participants include Developers, Technical Leads, Project Managers, Application Architects, Testers, and key infrastructure areas. This provides an early read on infrastructure requirements in preparation for the upcoming work effort. The Business team should be invited to this meeting as well. Performance testing should be addressed as early as possible in an Agile project. Non-Functional Requirements will evolve over time with the project, but should be addressed early in order to provide input to the performance team. Contact the performance testing team in the same timeframe as infrastructure. The Project Manager works with the Product Owner(s) to ensure that the Product Vision and Roadmap are in a state where they can be shared/reviewed with the team as a part of the project kickoff meeting. This table represents the types of activities (at a high level) that an Agile project would perform in the various sprints.

7 Sprint 0 Sprint 1 Sprints 2 through n Initial set up Sprint Planning Sprint Planning Infrastructure/Environment Architecture/Design Architecture/Design Prepare for development work Develop (code & unit test) Develop (code & unit test) in upcoming sprints Initial Architecture Test Test Validate scope of next sprint Sprint Demo Sprint Retrospective Validate scope of next sprint Sprint Demo Sprint Retrospective Example This table lists (in more detail) some of the activities that a typical Agile effort would perform during the sprints. Sprint 0 Sprint 1 Sprint 2 Set up: o Establish infrastructure o Establish Development and Test environments o Establish Development and Test data o Train the team o Obtain resource commitments o Establish PCB o Begin backlog grooming o Capacity and Velocity Planning o Pre-Planning for next sprint Initial Architecture (including) o Process Models o SAD o Information Architecture Stories 1, 2, 3, 4 Sprint Planning o Confirm the Stories to be completed during the current Sprint. o Confirm the detailed tasks that will be used to monitor Sprint progress. o Create the detailed Sprint Plan for the current Sprint o Obtain signoff on the Sprint Plan deliverable. Create Design for Iteration o Ongoing Architecture and design o Functional and nonfunctional requirement elaboration Perform Development Including: o Requirements o Unit test o Code drop to test environment Stories 5, 6, 7, 8 Sprint Planning o Confirm the Stories to be completed during the current Sprint. o Confirm the detailed tasks that will be used to monitor Sprint progress. o Create the detailed Sprint Plan for the current Sprint o Obtain signoff on the Sprint Plan deliverable. Create Design for Iteration o Ongoing Architecture and design o Functional and nonfunctional requirement elaboration Perform Development Including: o Requirements o Unit test o Code drop to test environment

8 Perform project planning activities Test Conduct appropriate testing for set of requirements in this sprint, both Functional & Nonfunctional o Unit/Integration testing o Regression testing of previous iteration o Testing Organization, (or QA Person)testing o Usability testing o UAT o Test Results Summary o Performance Testing as appropriate o Data Manufacturing Tasks Validate scope of next sprint o Plan and assess project status, risks, timelines & budget o Pre-planning for next sprint Complete the Sprint Demo o Including baseline verifications o This documents the review and retrospective in Agile terms o Approvals replace the formal WPR o Includes requirement, design, and test artifacts created as part of the sprint It is expected that teams will be familiar with artifacts, and will not need to spend additional time reviewing them Conduct Sprint Retrospective (lessons learned) Test Conduct appropriate testing for set of requirements in this sprint, both Functional & Nonfunctional o Unit/Integration testing o Regression testing of previous iterations o Testing Organization, (or QA Person)testing o Usability testing o UAT o o Test Results Summary Performance Testing as appropriate note final performance test needs to be regression in nature. o Data Manufacturing Tasks Validate scope of next sprint o Plan and assess project status, risks, timelines & budget o Pre-planning for next sprint Complete the Sprint Demo o Including baseline verifications o This documents the review and retrospective in Agile terms o Approvals replace the formal WPR o Includes requirement, design, and test artifacts created as part of the sprint It is expected that teams will be familiar with artifacts, and will not need to spend additional time reviewing them. Conduct Sprint Retrospective (lessons learned) Update Sprint and release Plan Progress Usually held to communicate key progress Update Sprint and release Plan Progress Usually held to communicate key progress

9 points to L2. Actual timing determined by the Team.) points to L2. Actual timing determined by the Team.) Sprint 0 It is important to note that Ideation should be completed before Sprint 0 begins. Agile Lifecycle Management (ALM) tool should be loaded with the appropriate project information when Sprint 0 starts so that activities and time can be properly planned and tracked. This includes Ideation initial allocations. For an Agile project, this normally includes Pre-Sprint 0 Planning, Sprint 0, Sprints 1-3. Sprint 0 is established as a fixed time period for readiness, logistics, preparation, and setup for Sprints 1 to n. The duration of Sprint 0 is determined by the team and is usually 4 weeks. The goal of Sprint 0 is to have as much in place as possible so that the team can actually deliver real working software by the end of Sprint 1. Typical activities in Sprint 0 include (but are not limited to): Formulate cross-functional team, including Product Owner (Business), Stakeholders, Scrum Master, Project Team. The Project Team may include: o Business Analysts o Developers o Architects o Infrastructure DBA MQ Web Eng CICS Infrastructure Lead Server Support o Quality Assurance Roles (e.g., Project Managers, SMEs, testers) o Production & Enhancement (P&E) o User Acceptance Testing Business Segment / Unit Lead o Designers o Other roles as appropriate for the work effort Conduct Agile Foundational Training with all team members Secure a collaborative working environment for the team or teams Create the Jira (or comparable tools) area for managing the Product Backlog, Release Backlog, Sprint Backlog, Release and Sprint metrics, and work items (stories, defects, observations, impediments, risks, etc.) Establish the project in ALM Establish SharePoint and/or Confluence wiki sites as a home base for the team's artifacts and communications. Form committees/workgroups that will work on Sprint 0 activities Outline Sprint 0 goals, objectives, and deliverables - What is being accomplished in Sprint 0 and by whom? Define the Sprint 0 fixed timeframe Agree on the length of upcoming sprints

10 Establish Sprint 0 Daily Scrum meeting time, place, and attendees The Application Architect builds out the initial set of Process Models to help drive the creation of the Product Backlog. The team (Development, Business Analyst, QA, Architect, Scrum Master, Product Owner) should create the initial prioritized, estimated Product Backlog. The Product Backlog may not have to have all the stories - just enough of the most important stories to start the first sprint. The stories for the first sprint should also have enough detail and clear acceptance criteria so that the team can begin work in Sprint 1 quickly. Stories are given a Story ID to distinguish them from other stories. The Application Architect begins building out the architecture solution in the Software Architecture Document (SAD). The SAD is updated from Sprint to Sprint so that it drives the detailed application/component design decisions being made within the Sprint. The Information Architect begins building the Information Architecture document. Establish a central repository for the Product Backlog so that everyone on the team can access it. It can be mechanical (low-tech), in some document (such as Microsoft Excel) or in a tool (Jira ). Team should determine the most efficient and effective approach for ease of use and accessibility. Establish information radiators that will be displayed and maintained, e.g., o Sprint burn down o Velocity chart o Story map o Release plan Create communication, feedback, support structure - feedback loop. This is for team and supporting groups/teams - this is the who/how to contact people. Include expectations for engaging people outside of the core team the pod turnaround times, engagement models, etc. Create initial work agreements - define how teams and managers will work together Establish what initial meaningful sprint metrics will be tracked and why - including non-software related metrics Define the team's initial Definition of Done - the team's commitment to quality. Example: o Successful local build o Locally unit tests - all test cases pass o Successful development build o Successful development test - unit tests - all test cases pass o Deployed to Development o Leave the code in better shape than it was before you changed it o Code Review o Artifacts complete o All acceptance tests approved by Product Owner and the acceptance recorded Identify applications and/or projects that may have an impact on or are impacted by this project. Begin work on plans to maintain alignment with the other efforts. Delivery Manager begins building the content of the and the Team Operating Guide. Build out the required infrastructure Meet with performance test team and share any non-functional requirements

11 1.4.2 Sprints 1 n Each sprint after Sprint 0 may contain the following activities: o Sprint planning o Backlog grooming (requirements/story elaboration) o Tasks creation o Resource assignment o Architecture work o Infrastructure work o Detailed design o Code refactoring o Coding o Access Path Analysis o Testing (includes Agile Test Results Summary for Sprint testing) o Reviews/Retrospectives o Product demos o Sprint Demo sign off of sprint documentation o Code merge, schema updates with concurrent projects. o Documentation and Training materials updates 2. Guidelines for Managing Agile Development Efforts 2.1 Project Set Up General Follow the Software Construction (Traditional) path, along with the guidelines noted in this handbook. Use the Meeting Agenda - Minutes template for meetings other than those standardized in the Agile process. Contact the project s Process Coach and Agile Coach for assistance. The Project should be set to Software Construction Traditional, and the project attribute should be set to Agile Development. Setting these attributes will allow Enterprise Architecture Governance and the metrics and reporting teams to identify that this is an Agile project and respond appropriately Planning Considerations Determine the number of sprints and high-level scope of each sprint and release, keeping in mind the following considerations: o Are requirements well prioritized so that highest priority and/or architecturally significant can be addressed first? By addressing the more architecturally significant features early, they then get the most exercise during the Agile testing. (Refer to Requirements section below.) o The team needs to work together in planning the sprint and release for optimal sequencing of work and management of dependencies and resources.

12 o What is the turnaround timeframe for business stakeholders to respond on design decisions during iterations? Decisions need to be made rapidly to keep effort moving forward; suggest establishing an agreed upon response time and business contact. o Dependencies on other project s development efforts. o Infrastructure dependencies o Are the essential people available for the required timeframes? What dependencies are there with the people needed? o The Project Manager must adequately plan for the Parallel Development Sync-up/Merge process, using the same techniques as a non-agile effort. (Note that this may be a much more complex task where the sync up involves both Agile and waterfall work.) o Plan to conduct performance testing approximately every 3 rd sprint or as needed Sprint Backlog Documentation The Sprint Backlog Documentation is a recommended artifact for Agile techniques. Sprint backlog must be updated in a real-time fashion in order to provide up to date, consistent information. Agile team members are responsible for updating work remaining and status of tasks as well as the status of stories on at least a daily basis before each scrum meeting. Scrum Masters and Product Owners are responsible for updating stories status as either accepted or rejected If a story has tasks that are not marked as completed, the person responsible for the task must update the status to indicate the proper state. No stories marked as complete should have tasks that are incomplete. If a task was unnecessary for story completion, it should be adjusted appropriately. Sprint backlog artifacts provide valuable information to all project stakeholders and other interested parties within the organization. They provide visibility into the current status of the stories and tasks, including work in progress, velocity, and story acceptance which is necessary for forecasting project delivery expectations. These documents also serve as valuable indirect artifacts for project planning. Teams will determine the best approach to storing and updating their backlog that allows access to all stakeholders. Document the agreement in the configuration management plan. Update the Requirements Management Plan to indicate that the standard traditional Requirements Management process will not be followed. o Business requirements are being documented in the User Story format. o Indicate where the Backlog will be located and managed. (Usually in Jira) o Story ID will be used to trace the stories to the Epics in ALM, Component Designs and to the Test Plan Forecasting In Ideation, if the project was identified to use Agile development techniques, then the Capitalized and Internal funding would have been adjusted to distribute resource hours evenly across those phases of the project. Ideation might not have determined the exact number of resources or the numbers of Agile scrum teams, so it is expected that the Manager will still need to adjust the forecast to align the dedicated resources and teams across the Pre-Sprint 0, Sprint 0 and Sprints 1-3 activities at project start (the beginning of Phase 4

13 for a Traditional project) and then again at the Exit Gate for the full lifecycle. Balancing the forecast once the project begins is important to insure the core scrum team resources stay dedicated to the Agile Effort Ensure that people that are not fully allocated to a project (e.g., infrastructure) are appropriately accounted for. If the project was not identified to use Agile in Ideation, the Capitalized and Internal funding allocations would have been loaded in a waterfall distribution. This will require a more significant effort by the Delivery Manager to balance the resource utilization if Agile development techniques are going to be used. Infrastructure should be involved early in the process (pre-sprint 0 if possible) and provide input for labor, hardware, and software costs as needed. 2.2 Business Team Follow standard Phase 4 procedures for locking budget and requirements. The timing of the locking should occur at the initial phase, which should be conducted at some point after Sprint #3. The Business phase takes the place of the Phase 4 Planning and Requirements Exit Gate that a non-agile project would complete. If requirement adjustments are discovered that impact scope, budget, or schedule after the Finance and Velocity Exit Gate, the standard Project Change Request process should be invoked. Since the closing phase occurs later for an Agile project than the Phase 4 Planning and Requirements Exit Gate in a non-agile project, it may impact hardware, software, and/or labor expenditures. The team should work with the appropriate parties from Finance and IT to determine the proper approach to securing funding at the proper times. Finance should be made aware as early as possible that the project is following Agile practices so that they can anticipate variations from standard procedures. There is a mechanism for obtaining Ideation hours for a project in order for Infrastructure to participate. Early engagement of Infrastructure is key, and hours should be available. 2.3 WBS and Estimation Workbook Estimation is a crucial part of any project planning effort. Project Planning and Control practices and CMMI indicate that estimates should be provided, using models and historical data. Adjust the Agile Work Breakdown Structure (WBS) to reflect the sprints by copying the sprint n activities as many times as there are sprints. Adjust any WBS Milestones as needed. Within a ALM Sprint WBS structure, there are only a limited set of tasks where allocations and time tracking are required. There is one task (Task: SPRINT n TIME TRACKING) where all resources will log actual effort for all tasks not related to creating, enhancing or reusing a First Class Service. A separate task (Task: SPRINT n SERVICE X ACTIVITIES) is created where all actual effort for each First Class Service is recorded and tracked. The Estimation Workbook may not provide the support needed for an Agile project to estimate the Sprint 1-n effort. Estimates for the Sprint 1-n work may need to be developed in other ways that make sense for the project. Since the Release level testing, Phase 6 Deployment and Phase 7 Project Closeout consist of the same activities and tasks as a Traditional waterfall project, estimates for those activities may be created by

14 using the standard IT Estimation Models, the Estimation Workbook, or some other approved estimation tool/model. TESTING ORGANIZATION, (OR QA PERSON) estimates need to take into account the sprint testing and estimate accordingly. Agile teams will provide estimates on a task by task basis as part of the normal Sprint planning work. These tasks/estimates should be properly recorded in the Sprint Plan and updated in a means that is accessible to the team and other stakeholders. 2.4 Requirements To maximize the benefits of developing software in an Agile fashion, requirements (stories) should be ranked in order of importance so that the highest priorities can be addressed in the earliest sprints. Factors to be considered when ranking requirements: business value, risk, dependencies, architectural significance, impact, complexity. The stories developed during the course of an Agile project can be used as requirements. The stories should have the proper level of detail so that interested parties (business, testing, design, development) have the information that they need. Stories should have unique identifiers so that traceability can be established between Epics, stories, testing artifacts, design artifacts, etc. 2.5 Traceability All project teams, whether Agile or waterfall, must maintain bi-directional traceability between Epics, requirements/stories, design artifacts, and testing artifacts. The term traceability refers to the ability to link the customers business needs to: Requirements at the beginning of a work effort Corresponding design artifacts Resulting software changes Associated testing artifacts Bi-directional traceability describes a model that provides the ability to start at any point in the traceability hierarchy and find a unique path back to the previous level and to the subsequent level. Portfolio Epics should link to one or more Enterprise Epics Program Level Epics should link to one or more Portfolio Epics Stories should link to the Epic Story (CT) that they are fulfilling. Stories that are decomposed must be traceable to the parent stories. Design documents and testing artifacts must be traceable to the appropriate stories. When a defect is logged, it should contain a link to the associated story.

15

16 2.6 Environment Obtain Business and Infrastructure Lead at project start to determine how the necessary development and testing environments will be secured for project effort based on the type and number of sprints. QA and Environments people should be involved in testing region discussions. Infrastructure, Testing Organization, Application Director, & Enterprise Resource Management must all agree on decisions regarding the environments and the environment schedules to be used for the effort. The performance team must be involved and non-functional requirements should be developed, updated, and shared regularly. Ensure Infrastructure team members understand sprint expectations and are in agreement as to the support their organization needs to provide for the effort to be successful. Agile teams often have requirements for 24x7 support during sprints (especially as the project nears completion), and appropriate planning and communications with the impacted team members is a necessity. 2.7 Architecture Application Architect - SAD Architects begin building the Automated Process Models and an overall design in the SAD during Sprint 0. The Process Models will provide a solid background for reviewing the Epics and developing feature based stories to be delivered. Architects should be working with the teams on an ongoing and consistent basis. At a minimum, they should participate in every Sprint Planning and backlog grooming sessions. When possible, architects should look ahead beyond the current sprint to provide architecture design input on stories for upcoming sprints. Architecture designs should be documented in a Software Architecture Document (SAD). The SAD template should be tailored in a way that makes sense for the project. Unlike a traditional project, the SAD will be a work in progress throughout the life of the Agile project. Each sprint can potentially require architecture design; if so, the SAD should be updated to reflect the requirements of that sprint. When the next sprint starts, if more architecture work is needed, the SAD should be updated to reflect that new work for the new sprint. Indicate the changes that were made for each sprint in the Revision History section of the document. The SAD can also contain separate sections for each sprint, if that is appropriate for the required work. The SAD should go through the Infrastructure SAD Review at appropriate points. It may or may not be necessary to review the SAD at every sprint, but if there are significant changes to warrant a review, get on the agenda for the appropriate meeting. The Architect and Infrastructure Manager will determine if attendance at the meeting for the project is necessary. For example, it may make sense for an Agile project to review the SAD with Infrastructure every 3 sprints. Given the short timeframes of sprints, it may not be possible to submit the draft of the SAD 3 days before the SAD review. However, teams should complete the SAD Review Attendee Checklist 10 days before the review, and submit the remaining SAD documentation as early as possible (ideally 2-3 days before the SAD review). The actual timing of the submission of documents can be discussed and agreed to between the project team and infrastructure.

17 Depending upon the nature of the changes, a separate Business Infrastructure Manager (BIM) team review may not be necessary following every Infrastructure SAD Review. During the Infrastructure SAD Review, it should be determined if the BIM review is required Information Architecture (IA) Information Architecture designs should be documented in an Information Architecture Document (IAD). The IAD template should be tailored in a way that makes sense for the project. Unlike a traditional project, the IAD will be a work in progress throughout the life of the Agile project. Each sprint can potentially require architecture design; if so, the IAD should be updated to reflect the requirements of that sprint. When the next sprint starts, if more architecture work is needed, the IAD should be updated to reflect that new work for the new sprint. Indicate the changes that were made for each sprint in the Revision History section of the document. The IAD can also contain separate sections for each sprint, if that is appropriate for the required work. During Sprint 0, the Information Architecture should become involved with the sprint teams and produce artifacts as necessary. It is possible that some sprints may have no Information Architecture artifacts. A contextual overview should be documented in the IAD, and provided in the earliest sprint possible (ideally Sprint 0). This may be expressed through a Conceptual Data Model or freeform text, and describes the key concepts. Access Path Modeling should be performed during a sprint as necessary. A Physical Data Model may be required in order to provide database changes needed to support completion of development and testing within a Sprint. The Information Architect and the DBA should be looking a few Sprints ahead so that data structures needed for Sprint testing can be in place when required, A collaborative approach between the Information Architect and Application Architect should be maintained throughout the Sprints. This will allow the IA to keep pace with the data analysis as the Sprints progress. 2.8 Testing Testing Organization, AppDev, Business, and Application Architect must all be part of decision on how and when testing will be conducted and what types of testing will be conducted in each sprint. Determine if there are any special considerations as to the Testing tool within ALM setup due to sprints. Indication must be made when items are ready to be tested. This can be done via meeting minutes, , or status changes in backlog documentation Sprint Level Testing Testing within a Sprint is primarily focused on Story level testing Unit testing is done in Dev environment Once the developer is satisfied the story is unit tested, it is dropped to QA for System testing The Testing Organization (or QA Person) develops a test plan, test scenarios, and test cases for the Stories in each Sprint based on the stories acceptance criteria. A Test Plan will be completed incrementally from sprint to sprint. A separate tab for each sprint is recommended.

18 Testing ALM tool keeps a record of each test case and the execution results. Sprint level Test Cases developed will become part of the Release Level System Test Suite Some or all of the test cases within the Release Level System Test Suite could be added to the application level Regression test suite. Sprint level Regression testing may be done as needed. This testing simply reruns scripts from prior sprints to confirm functionality from prior Sprints still functions as expected. This is not the same as the application level regression testing done during release level testing. User Acceptance Testing may be done when there is sufficient end-to-end functionality for the business to assess the usability of the functionality being delivered. UAT Execution Plan with Test Cases should be developed incrementally as the sprint work is completed. When the project moves to the Release test environment an end-to-end UAT is performed. This incremental UAT plan should provide most (if not all) of the information necessary for a full UAT effort on the completed functionality. A Performance Testing Assessment should be conducted by the Performance Testing Technical Lead following the Infrastructure SAD Review(s). Non-functional Requirements (in the form of a formal NFR document or within stories) are a key input to performance testing. If multiple SAD reviews are performed, then the Performance Testing Strategy (PTS) should be done on an incremental basis. Each increment should correspond to the content of the related SAD. The PTS can be done as one document, as long as there is a clear delineation of the contents of each increment. Test Results Summary - An Agile-specific Test Results Summary (TRS) template is available in the methodology. This template has been tailored to reflect the likely activities of an Agile effort. There is only 1 tab to be completed in the Agile TRS. This tab may be updated over the course of the sprints, or it may be completed once when all Sprint testing to date is complete. There is a column to indicate the type of testing (UAT, System, etc.). Other columns and sections of the template are the same as the non-agile template. Teams can choose to record results on a sprint-by-sprint, story level, or a higher level Release Level Testing Once all Sprints are completed and the code has been moved to the Release test environment, Release Level testing begins. Standard Agile Outlook Test Plans, Test Scripts and Test Results Summaries are created for all release level testing in the same format and with the same content as a standard waterfall project or SR Regression Testing Regression Testing is done at the application level for each release. A Regression Test Plan is created or re-used. The Regression Test Suite is run during the normal Release Regression test window. Test cases covering the current release changes can be added to the suite, if applicable, once the release is completed. Complete the standard methodology Regression Test Results Summary System Testing

19 Due to the extensive system type testing done during the Sprints, release level systems testing may not be required. In this case, the Agile project may be granted permission for late code drop for the release test cycle. The Agile code must be available as needed for the other types of testing done at the release level. If release level Systems testing is required, the Test Plan(s), Test Cases used for Sprint testing are used to create system tests suite Complete the standard Test Plan and Test Results Summary Specialty Testing Determine how and when specialty testing will be conducted, if required. Complete the standard FIS-APLC Test Plan and Test Results Summary for Specialty testing Vulnerability Testing Projects that require vulnerability code scans must work closely with the Security Team to plan, budget, schedule, and run the code scan (Ounce Labs) and Appscan tools. The Application Development Manager will delegate a representative per release to coordinate security vulnerability code scans per application with the Security Team End to End Testing If the applications involved in the Agile effort are a part of the release end to end testing effort, they must ensure their code is available for the release level end to end testing when that testing will occur User Acceptance Testing UAT should include evaluating the usability of the application from a business user s perspective. Complete the standard FIS-APLC UAT Execution Plan and Test Results Summary for User Acceptance testing Automation Testing Assess impact to automation testing. Engage automation testing resources during Sprint 0, and work with the team to determine the appropriate level of engagement for the project Testing Documentation Test Plan - When creating the test plan, indicate the sprint # on the General Information tab. A separate test plan can be created for regression/system testing, if there is a dedicated sprint for this purpose at the end of a project. A Test Plan will be completed incrementally from sprint to sprint. A separate tab for each sprint is recommended. o On the Test Plan tab, indicate who performed the test, when it was performed, and the expected result. o The Requirement ID/Name can be the Story ID/Name. Depending upon how requirements are defined and documented, the Requirement ID (e.g., FUN001) can be used, or if requirements are done on the story level, use the Story ID. However, this is done, be consistent throughout all artifacts.

20 o It may be helpful to add a column to the test plan to indicate that User Acceptance Testing (UAT) was done on the story during the sprint. Normal acceptance of the stories involves the business looking at the completed work. UAT should be performed on the entire completed functionality, but the incremental UAT can help to ensure that individual pieces of the solution perform as expected from the business perspective. o A UAT Test Plan should be developed incrementally as the sprint work is completed. When the project concludes and end-to-end UAT is performed, this incremental UAT plan should provide most (if not all) of the information necessary for a full UAT effort on the completed functionality. Testing Strategy -The existing testing strategy template can be used as is. If there are any tailoring opportunities, note them in the Project Deliverables List (PDL). The WPR of Testing Strategy should be held when the strategy is complete. This may occur after the first sprint has started; indicate the appropriate date for the WPR in PlanView. Test Results Summary - An Agile-specific Test Results Summary (TRS) template is available in asset library. This template has been tailored to reflect the likely activities of an Agile effort. Teams can use this template or the standard template if that suits the needs of the project. As with all templates, teams may choose to tailor the TRS in a way that is useful for their effort. It is important to remember that script counts, defects, and traceability must be completed for all efforts. Teams are assessing the risk of releasing the code. o There is only 1 tab to be completed in the Agile TRS. This tab may be completed during the course of the project, or it may be completed once at the end of the project. There is a column to indicate the type of testing (UAT, System, etc.). Other columns and sections of the template are the same as the non-agile template. Teams can choose to record results on a sprint-by-sprint, story level, or a higher level o o o o o o o Performance Test Results Summaries will be completed the same as for non-agile projects. Integration testing for many Agile efforts, the unit and integration testing is combined. If so, the Test Strategy should be updated to indicate that this is occurring. If separate Integration testing is performed, record the results as usual. User Acceptance Testing (UAT) business should conduct UAT before the release. Business flow scenarios should be tested. Currently, business participates in the acceptance of stories, but they should verify that all parts of the application flow properly during the sprints. Specialty testing depends upon the nature of the project. If specialty testing is performed, record the results as usual. Approvals will be obtained using the Testing tool. To ensure traceability of defects, the story number and/or requirement ID should be recorded. Columns can be added to the Test Results Summary to record sprint number and/or team name if desired Defect Tracking Findings (Observations)

21 There are times when a finding is identified and immediately corrected as part of the agile effort. In those instances, it is not required to log the finding unless the team wishes to log it. It is recommended that if the finding is not addressed right away that it be logged so as not to be missed and to ensure it is provided appropriate priority. A finding, rather than a defect, will be logged when identified within the current sprint for the stories within that sprint, when not resolved right away. If a finding is open at the end of the sprint that is defect related, then the finding should be logged as a defect in Testing Tool or JIRA based on the tool the team is using. The story will remain open but if it can be resolved early in the next sprint the team can identify that and when closed in the next sprint they will receive credit for the story. If, however the finding is a related to a new or expanding requirement then the finding should be converted to a story and placed into the product backlog. Defects A defect will be logged when an observation is found in the current sprint related to a prior sprint(s) e.g. You find a defect while in sprint 2 related to a sprint 1 story. All release regression script failures should be logged as defects all environments After production deployment all issues should be logged as defects in testing tool Defect Tracking JIRA or Clear Quest Project teams can determine the tool selection that best fits their needs when logging findings or defects prior to moving into the release path. Findings (Observations)/defect tracking should be consistent across all teams, regardless of the tool they are tracked in. When the code merges into the release deployment path, all findings/defects need to be logged in testing tool and should also be entered in JIRA for purpose of backlog grooming. Direction will be reassessed as the Enterprise Reporting capability is expanded to include JIRA data. The team should work the observations/findings as part of their daily activity during the sprint cycles triage meeting not required. Triage meetings will be conducted when the code merges into the release deployment path. 2.9 ERM (Enterprise Release Management) Agile Development will indicate to ERM those efforts that are following the Agile approach and may therefore fall outside of the published interim milestones. Once the team has defined the impacted applications and targeted production installation date, submit to Business. As ERM manages across domains, their awareness of those projects working in an Agile fashion allows them to identify potential issues as release testing is being conducted Infrastructure It is essential to engage the Business team at project start during Sprint 0, as they are critical to the success of the sprints. Continued participation throughout the project is necessary.

22 Acquire Infrastructure Lead at project start so they understand the development approach and can assist with coordinating the overall infrastructure and environment. The nature of iterative development using sprints results in design activities that are ongoing throughout the life of a project, as opposed to traditional waterfall projects whereby heavy design is done upfront. Sprints also have a short repeated cycles, generally 2 or 3 weeks. In order to properly review requirements designs and respond to potential issues, Infrastructure must be involved in Sprint Planning and Backlog Grooming activities. If during Sprint Planning, Infrastructure determines that close involvement is required, then the individual(s) from Infrastructure will participate in the sprint activities. This includes Infrastructure attendance at the Daily Scrum meeting, backlog grooming, and other sprint activities Infrastructure Checklist for new Agile Project Startup The purpose of this checklist is to have an early meeting with the Agile technical team and key infrastructure areas (such as TDM, SSS, etc.) to identify large or complicated infrastructure requirements. If these requirements are identified and analyzed early in the process (i.e. pre-sprint 0), infrastructure is in a better position to meet the needs of the project for Sprint 1. How to use this checklist. The Infrastructure Manager (IM) will set up a 30-minute meeting with the project technical leads and key infrastructure areas. The IM should work through the same infrastructure managers as they do for normal project work in order to identify who should attend this meeting. During the meeting the IM will go through each item on the list below, asking if there are any known or possible impacts. If any answers come back as yes, the IM may need to setup additional meetings with the specific resources from ADA and IIS. Early Read on Infrastructure Requirements Checklist Capacity Requirements and Storage: are there any considerable capacity requirements. o Storage/DASD (MF, MR, other types of storage requirements) CICS: are there any considerable CICS requirements o New Region requirements, new transactions/coors of significance. CAM o New Clear case o New Endevor Database (Mainframe, Midrange, SQL) BIM Team MQ Production Control (Batch) Delivery Environment (paths) Security Engineering Web Engineering Reporting (Crystal/BOE) Hardware: Server Support Unix/AIX/Linux/Other Hardware: Windows/Other LPAR/MIPS considerations