capability pattern handbook - agile...1.3 roles and responsibilities ... agile development. 1.3.1...

Agile Resources – Series 2 Traditional Software Development to Agile Development Transition

A Sample Reference Handbook For more resources please visit http://www.agileoutlook.com

This is a sample reference guide for organizations planning to go Agile. It is incomplete, not well edited and based on hypothetical organizational context. For help with comprehensive and customized Agile Handbook or Playbook for your organization, please contact Agile Outlook [email protected]

Table of Contents Purpose ........................................................................................................................ 3 Criteria for Using Agile Development Techniques ......................................................... 3 1. Agile Overview ..................................................................................................... 3

1.1 Definition of Agile Development..................................................................... 3 1.2 Benefits of Agile Development........................................................................ 4 1.3 Roles and Responsibilities ............................................................................... 4

1.3.1 Scrum Master .......................................................................................... 4 1.3.2 Product Owner ......................................................................................... 5 1.3.3 Agile Coach ............................................................................................. 5 1.3.5 Delivery Manager Manager ...................................................................... 5 1.3.6 Existing Project Roles .............................................................................. 6

1.4 Mapping Agile Development to Traditional Software Development.................. 6 Pre Sprint 0 –Project Set-up ................................................................................... 6 1.4.1 Sprint 0.................................................................................................... 9 1.4.2 Sprints 1 – n........................................................................................... 11

2. Guidelines for Managing Agile Development Efforts ........................................... 11 2.1 Project Set Up ............................................................................................... 11

2.1.1 General .................................................................................................. 11 2.1.2 Project Deliverables List (PDL) ................. Error! Bookmark not defined. 2.1.3 Planning Considerations ......................................................................... 11 2.1.4 Sprint Backlog Documentation ............................................................... 12 2.1.5 Forecasting ............................................................................................ 12

2.2 Business ........................................................... Error! Bookmark not defined. 2.4 Requirements ................................................................................................ 14 2.5 Traceability................................................................................................... 14 2.6 Environment ................................................................................................. 16 2.7 Architecture .................................................................................................. 16

2.7.1 Application Architect - SAD ................................................................. 16 2.7.2 Information Architecture (IA)................................................................. 17

2.8 Testing ......................................................................................................... 17 2.8.1 Sprint Level Testing ....................................................................................... 17 2.8.2 Release Level Testing ..................................................................................... 18

2.8.2.1 Regression Testing ................................................................................... 18 2.8.2.2 System Testing ........................................................................................ 18 2.8.2.3 Specialty Testing ..................................................................................... 19 2.8.2.4 User Acceptance Testing .......................................................................... 19

2.8.3 Automation Testing ........................................................................................ 19 2.8.4 Testing Documentation ................................................................................... 19 2.8.5 Defect Tracking.............................................................................................. 20 2.9 ERM (Enterprise Release Management)......................................................... 21

http://www.agileoutlook.com/




2.10 Infrastructure............................................................................................. 21 2.10.1 Infrastructure Checklist for new Agile Project Startup ............................. 22

2.11 Gates & Reviews ....................................................................................... 23 2.11.1 WPR of Planning Deliverables ............................................................... 23 2.11.2 Sprint Demo .......................................................................................... 23 2.11.3 Sprint Retrospective ............................................................................... 24 2.11.4 Enterprise Architecture Governance (EAG) Reviews .............................. 24 2.11.5 Finance and Velocity Exit Gate .............................................................. 24 2.11.6 Finance and Velocity Exit Gate Summary ............................................... 25 2.11.7 Sprint Progress Gates ............................................................................. 25

2.12 Configuration Management........................................................................ 26 2.13 Change Management ................................................................................. 26 2.14 Quality Management ................................................................................. 26 2.15 Transition / P&E Support........................................................................... 27 2.16 Warranty Period ........................................................................................ 27 2.17 Function Points ......................................................................................... 27 2.18 Partner Satisfaction Survey ........................................................................ 27

Appendix A ................................................................................................................ 28 • Terminology of Agile Development .................................................................. 28

Appendix B ................................................................................................................ 32 • Meetings specific to Agile ................................................................................ 32

Appendix C ................................................................................................................ 33 • Agile Project Dashboard ................................................................................... 33

Revision History ......................................................................................................... 34





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 [email protected] 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.





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.

1.3.1 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





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

1.3.2 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

1.3.3 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.

1.3.4 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.





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.





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 in upcoming sprints

Develop (code & unit test) Develop (code & unit test)

Initial Architecture Test Test Validate scope of next sprint Validate scope of next sprint

Sprint Demo Sprint Retrospective

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

Stories 1, 2, 3, 4

Sprint 2

Stories 5, 6, 7, 8 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

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.

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.

Initial Architecture (including) o Process Models o SAD o Information Architecture

Create Design for Iteration o Ongoing Architecture and

design o Functional and non-

functional requirement elaboration

Create Design for Iteration o Ongoing Architecture and

design o Functional and non-

functional requirement elaboration

Perform Development Including: o Requirements o Unit test o Code drop to test

environment

Perform Development Including: o Requirements o Unit test o Code drop to test

environment





Perform project planning activities

Test Conduct appropriate testing for set of requirements in this sprint, both Functional & Non-functional 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

Test Conduct appropriate testing for set of requirements in this sprint, both Functional & Non-functional o Unit/Integration testing o Regression testing of

previous iterations o Testing Organization, (or

QA Person)testing o Usability testing o UAT o Test Results Summary o 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

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

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)

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





points to L2. Actual timing determined by the Team.)

points to L2. Actual timing determined by the Team.)

1.4.1 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





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





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

2.1.1 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.

2.1.2 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.





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 3rd sprint or as needed.

2.1.3 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.

2.1.4 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





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





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.





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

2.7.1 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.





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.

2.7.2 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,

email, or status changes in backlog documentation.

2.8.1 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.





• 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.

2.8.2 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. 2.8.2.1 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. 2.8.2.2 System Testing –





• 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. 2.8.2.3 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. 2.8.2.3.1 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. 2.8.2.3.2 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.

2.8.2.4 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.

2.8.3 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

2.8.4 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.





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 Performance Test Results Summaries will be completed the same as for non-Agile projects. o 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.

o 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.

o Specialty testing – depends upon the nature of the project. If specialty testing is performed, record the results as usual.

o Approvals will be obtained using the Testing tool. o To ensure traceability of defects, the story number and/or requirement ID should be recorded. o Columns can be added to the Test Results Summary to record sprint number and/or team name if

desired.

2.8.5 Defect Tracking Findings (Observations)





• 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.

2.10 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.





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.

2.10.1 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





2.11 Gates & Reviews Based on the nature of the functionality being developed, WPRs and gates must be set at the appropriate time based on the sprint schedule.

2.11.1 WPR of Planning Deliverables This WPR can be accomplished just prior to the Finance & Velocity Exit Gate. The purpose of this WPR is to review the product backlog, release plan, the final proposed estimate and schedule to be presented at the exit gate and the TL4000 IPP and related plans. This should be done at a time when the product backlog has been reviewed and each story has been given an estimate and priority. The stories that the team has committed to should be clearly documented. The team should provide sign off using the electronic signature tool to indicate the lock down of scope for the Finance and Velocity Exit Gate and the proposed project total forecast/budget.

2.11.1.1 WPR of Planning Deliverables and Testing Tool Create a review record in ClearQuest: Title the ClearQuest review record ‘Project Number WPR of Planning Deliverables. Include the artifacts that will be reviewed. Among the artifacts that can be reviewed:

o Product Backlog o Release Backlog o Sprint Backlog o WBS

Ensure that the appropriate roles (L1 team members) are listed as approvers in the ‘Request Signatures’ tab.

2.11.2 Sprint Demo The Sprint Demo functions as a deliverable to collect approvals for the contents of all Sprints that have

occurred since the beginning of the project or since the last Sprint Demo. The project is tailored to indicate that approval of requirements, design, and testing is accomplished within testing tool using the deliverable. It is important to note, however, that the team can choose to hold separate WPRs for each of these if they choose to do so. The Sprint Demo record is important evidence that indicates team approval for the sprint contents.

The frequency of the Sprint Demo for an Agile project is recommended to be at the end of every sprint. Some teams may find it more appropriate to perform the Sprint Demo at a different interval but intervals longer than 3 sprints are not recommended. This will allow too much time and development activity to pass, and in the event of a problem, could cause significant rework and negative impact to the project.

Create a new instance of the Sprint Demo deliverable record in ClearQuest for the Sprint Demo; Be sure to note the Sprints included in the PCR field of the deliverable record.

List the deliverables that were created or updated during the Sprints in the Project Team Comments field on the Supporting Details tab of the deliverable. In essence, these represent the artifacts that are being approved.

Request signoff from appropriate Business stakeholders, including the Product Owner. There should not be a need for team members to sit and do a formal review at this time. It is expected that the team





members will be participating in document review and updates as needed as the sprint proceeds. Confirm that the sprint delivered the scope, objectives, and products as initially defined. If stories got rejected or additional stories got added to the Release Backlog/Product Backlog, determine the impact on future sprints and overall project delivery, adjust the content of future sprints as needed, and complete the PCR process if necessary.

2.11.2.1 Sprint Plan Review The purpose of this review is to provide evidence that the team has reviewed and is in agreement with the detailed workplan for the given Sprint (required by Sarbanes Oxley and other audits to demonstrate stakeholder commitment to the plan.) Hold the Sprint Planning Meeting. Team confirms the size (story points) and priority (order) for the

stories included in the Sprint Backlog. Scrum Master and team build out the detailed tasks, assignments and schedule for all of the stories to be

addressed during the Sprint. Ensure that the appropriate roles are included in the meeting. Project Manager creates an instance of the Sprint Plan deliverable in the Project Deliverables List and

requests approvals from the required roles via CQ.

2.11.3 Sprint Retrospective The Sprint Retrospective provides the team with the opportunity to discuss things that worked well during the Sprint and any Lessons Learned that can be applied to make the subsequent Sprints more effective and efficient. Best Practices and Lessons Learned that could benefit other teams should be captured in the IT Best Practices/Lessons Learned Library as well as within JIRA and made available to assist other teams. This will increase the effectiveness and therefore value (ROI) of the Agile process at FIS.

2.11.4 Enterprise Architecture Governance (EAG) Reviews

EAG reviews must be requested at the following times in the agile project lifecycle: After the initial architecture is available Every time there are architecturally-significant changes since the last EAG Review After implementation, when the architectural documents include the final design

2.11.5 Finance and Velocity Exit Gate The Phase 4 Planning & Requirements Exit Gate should be called the ‘Finance and Velocity Gate’ for

an Agile effort, since the Phase 4 terminology doesn’t apply. This gate serves as a progress checkpoint to lock down the budget for the project, and review resources,

schedule, and scope. In an Agile project, the labor budget is fixed; people are committed throughout the life of the project. The end date is fixed as well, which leaves scope as a variable component. The Product Owner is constantly involved with the team to ensure that items of highest priority get completed. The implication is that the full scope of the project may not be known at the time of the





gate. The team can estimate scope based upon their velocity and team capacity, but the scope is subject to change based upon the prioritization of the Product Owner.

The Finance and Velocity Gate should occur after enough sprints have completed to allow the team to determine their baseline velocity. Based upon the velocity, the team should be able to examine the product backlog to determine the scope of the project based upon the scheduled release(s) and funding. For most projects, this will occur after Sprint 3. Update the milestone in PlanView to record this date.

Set and update the milestones ‘Project Budget Approved’ and ‘Finance &Velocity Gate-Complt’ in Planview following the gate. This will serve as an indicator to reporting and metrics teams that this gate has been completed.

2.11.6 Finance and Velocity Exit Gate Summary The Finance and Velocity Gate Summary document is available in the FIS-APLC (Exit Gate Summary

(Agile)). It is based upon the non-Agile exit gate summary document, and has sections that were changed to reflect the Agile effort. Some items to consider include:

o Timeline/Milestone: Indicate the WPRs that the Agile project will conduct. Include the revised Phase 4 Exit gate timing, as well any Sprint Demo meetings.

o PQA (Process Quality Assurance) Status – indicate the planned dates for PQA reviews. These dates should be an agreement between the project team and the PQA representative.

o Work Product Review Approvals – indicate the types of WPRs that will be completed for this effort.

Deployment Readiness Exit Gate – This gate is included in the Exit Gate Summary (Agile) template. Because our current Agile process only delivers code into production in conjunction with an ERM release, the project will hold a Deployment Readiness Exit Gate at the conclusion of Systems testing for the release, just as a waterfall project would. The project then enters standard warranty period with the same processes as a waterfall project. Defects are fixed and deployed as standard Warranty Deployments. Defects may either be fixed using the Agile sprint approach if the support team is continuing with Sprints or in the same manner as defects for the non-Agile teams.

Transition Readiness Exit Gate- This gate is included in the Exit Gate Summary (Agile) template. It is held at the point where all functionality that will be delivered in conjunction with the project will be turned over to the production support organization for ongoing support and maintenance.

2.11.7 Sprint Progress Gates Design and development are ongoing processes throughout all sprints in a project. Traditional Design

and Development gates are not applicable. However, there should be periodic gates in place of the Design and Development gates. These can take the form of ‘Sprint Progress Gates’ and can occur at various points within the lifecycle. The first of these should occur after several sprints have completed, in advance of any release activity. Additional gates should be conducted as warranted by the size and complexity of the project. There is an Agile-specific exit gate template that should be used for this gate as well as the Finance and Velocity gate.

Timeline/Milestone: Indicate the WPRs and/or Sprint Demos that the Agile project will conduct. Include the revised Finance and Velocity gate and Sprint Progress Gates, as well any Sprint Demo meetings.





PQA (Process Quality Assurance) Status – indicate the planned dates for PQA reviews. These dates should be an agreement between the project team and the PQA representative.

Work Product Review Approvals – indicate the types of WPRs and/or Sprint Demos that will be completed for this effort. Sprint Demos that will cover requirements, design, and testing are normally completed at the end of every sprint. WPR’s are normally not required for Sprint level work, but may be added at the discretion of the team.

Other Document Approvals – add any appropriate artifacts (e.g., Disaster Recovery Plan, Technical Pre-Screening Checklist, etc.)

2.12 Configuration Management Baseline documents in the sprint where they were created or updated. When baselining documents,

include the project number and sprint number in the label. For example, the label can be ‘Project Number_Sprint1_baseline’.

Perform Baseline Verifications just prior to the Finance and Velocity Gate and prior to code migration for release testing.

Avoid “multi-pathing” development streams for different release cycles (apply all project team members to the next release), and minimize branching.

Project-level deliverables are created once and updated throughout the sprints (not individual project documents per sprint).

Ensure Parallel Development Sync-up/Merge tasks are clearly laid out in Sync/Merge Code section of Configuration Management Plan.

2.13 Change Management Follow the Project Change Management procedure as outlined in the Conduct Project Tracking and Control section of the methodology. In Agile projects, the scrum team (Scrum Master, Product Owner, BAs, developers, testers, etc.) is flexible in adjusting to changing business priorities. Stories within the product backlog will likely change in priority and ranking from sprint to sprint. For small scope changes, PCRs may not be necessary, but PCRs would be used for large scope, financial, infrastructure, or schedule changes. Some examples requiring a PCR would be: Additions or changes to the backlog that will cause the total cost of the project to exceed what was

approved at the Finance and Velocity Exit Gate, Functionality that was originally included in the backlog and was considered in-scope for the scheduled

release gets ‘bumped out’ of the release either into a second release or is deemed out of scope for the project.

An approved release date must be changed. Costs originally targeted for one year must be moved or carried over into the next year.

2.14 Quality Management Review sprint strategy with assigned PQA Representative to determine approach for the Process Assurance Reviews and complete the PQA Review Schedule. A suggested approach would include a review after the Finance and Velocity Exit Gate (between Sprints 3 and 6), a combined design/development/deployment review after each deployment, and a transition review.





2.15 Transition / P&E Support Projects should reach out to the Production Project Manager (PPM) and/or Domain Manager at the start of the project. A transition plan is required for all Agile and non-Agile projects. P&E may not need to be a full time participant in the team. However, P&E should be invited to all Sprint Demo sessions in order to begin the process of becoming familiar with the upcoming changes. As the project proceeds and draws closer to releases, P&E can become more actively involved as necessary.

2.16 Warranty Period Post production defects for Agile projects should be analyzed and addressed according to their severity and priority. Urgent/Emergency fixes should be addressed immediately, like any other eFix. Lower severity/priority items can be addressed in a couple of ways: If the project is still in progress (defect appeared after a release, but while sprints are still ongoing), enter

the defect into JIRA as part of the product backlog. It will get estimated, prioritized and added to a sprint as necessary.

If the defect follows the end of the project, treat the defect as in the traditional FIS-APLC path.

2.17 Function Points One required Final count and one optional count for PCRs will be conducted per project. For projects with Agile capability patterns, counting activities will be initiated by the Function Point team at the last project deployment and completed with support from the project team as needed. The scope for the counts will include all stories and/or requirements delivered by the project. If there are any questions about the function point process, or if assistance is needed, please contact the Function Point mailbox.

2.18 Partner Satisfaction Survey The Partner Satisfaction Survey must be conducted periodically throughout the Agile project, as it is for non-Agile projects. For Agile projects the survey should be conducted after the 3rd sprint and then every 3rd Sprint after that, up to 4 surveys. The final survey should then be conducted after the last deployment.





Appendix A

• Terminology of Agile Development

Term Definition Acceptance Criteria

The conditions that indicate that a story is completed. For the example story “As a Student I want to purchase a parking pass so that I can drive to school", acceptance criteria may be: - Parking pass is received - Receipt for parking pass is printed

Daily Scrum Meeting

Daily – Time-boxed to 30Minutes Everyone invited, but only Scrum Master, Product Owner or core team “the pod” can talk

During the first 15 minutes, 3 Questions are answered by each team member:

o What did I do yesterday? o What will I do today? o What is standing in my way?

Not a status meeting

Definition of Done The Definition of Done is a checklist created/agreed to by the core team members (before sprinting) to ensure that the team is delivering features/stories that are truly completed or done. The list should add verifiable/demonstrable value (or quality) to the product. In a sprint, stories are not considered "done" until all the items on the team’s list are complete.

Feature / Story User Stories are a specific form of requirement artifact used in Agile projects. They lend themselves well to Backlog prioritization and granular feature development. These may replace or map to other requirements artifacts (Expanded Business Needs, Use Case Requirements, functional and/or non-functional requirements). In all cases Agile requirements should be articulated to clearly express “something of business value” to the end user or business owner. An example of a story might be: "As a Student I want to purchase a parking pass so that I can drive to school"

Other Meetings (non-Agile specific)

Weekly Manager Update – this meeting is useful as a means to bring managers up to date with the status of the sprint activities,





especially when there is more than one sprint team. This meeting is also referred to as a ‘Level 1.5’ meeting. The purpose of the meeting is for the project managers to provide status to other stakeholders, and to provide the chance for Q&A by interested parties that are not normally part of daily scrum sessions. This is also an opportunity for project managers to resolve risks with managers of other departments and remove impediments for the team.

Product Backlog A repository of epis and stories the project might deliver. Stories are stack-ranked according to Product Owner’s prioritization, technical sequencing, and/or estimation. The top tier of the Product Backlog may become part of the Sprint Backlog for next sprint, as determined by the Product Owner. The sizing of the entire backlog should be done by the team prior to Sprint 1. As stories get added to the Product Backlog throughout the project, estimation session will need to occur during the backlog grooming. Estimation is performed by doing relative comparison to a baseline story that the team has established.

Product Roadmap The high level schedule of deliveries or releases, specifying goals and high level functions (future release’s content evolves in Agile projects)

Product Vision The high level statement of the project’s beneficiaries, purpose, and benefits

Release Plan The schedule of sprints leading to releases, with some indication of what features will be done each sprint. This is a working plan and future sprints’ content changes dynamically based on Product Owner changes to Product Backlog.

Scrum Scrum is an iterative, incremental framework for developing any product or managing any work. It allows teams to deliver a set of functionality designed, coded, tested, and accepted by business within each sprint. It provides the agility needed to respond to changing requirements and priorities.





Sprint A Scrum iteration (repeated cycle) Scrum projects show progress in a series of time boxed

“sprints” Typical duration for a Sprint is 2–3 weeks A constant duration leads to higher discipline and a better

rhythm Product is designed, coded, tested, and accepted by

business during the sprint Work is planned in Sprint Planning Meetings at the

beginning of each sprint Completed work is demonstrated and approved with

interested parties at the end of the sprint cycle, known as the sprint demo

Consistent sprint cadences provide synchronization and release points to coordinate and integrate with multiple projects or teams

Sprint Planning Meeting

Occurs on the first day of the sprint Define sprint goal Create Sprint Backlog from product backlog items (user

stories / features) Team commits to completing the stories that they have

committed to Product Owner approves the sprint backlog Tasks are created and estimated in hours against each

story within the sprint backlog

Sprint Retrospective Meeting

Occurs on the last day of every sprint Typically, 60-90 minutes Review previous sprint in regards to what worked well

that the team wants to continue doing and what did not work well that the team would like to improve upon for the next sprint

Team vote on the top 3 items that they would like to

improve upon by creating action items with assigned ownership

Exclusive to the core team, namely Scrum Master, Product Owner, BA, Dev, and ETQA





Sprint Demo Meeting

Team demonstrates completed stories to each other, Business Stakeholders, and Product Owner to get early feedback Informal

o 2-hour prep time rule o Not a meeting for PowerPoint slides – show

working software Everyone is invited

Product Backlog Grooming

Objectives of the backlog grooming session are: o Create/elaborate/clarify new and existing stories, o Decompose big stories into granular stories o Prioritization and ranking of stories o Story sizing/estimation o Ensure each story contains clear acceptance

criteria for providing scope for development and testing

Ensure top tier of the product backlog/release backlog have clearly defined acceptance criteria in preparation for the upcoming sprint planning

Backlog grooming is an ongoing, collaborative effort, that needs to happen routinely either with the Product Owner and Stakeholders, or the Product Owner and Scrum Master, and, at other times with the Product Owner, the Scrum Master, and the Team to ensure a common/shared understanding of story. The Team (including the Product Owner) should decide on a regularly scheduled day and time for devoting to the backlog grooming.

Estimation/sizing of stories also occurs during the backlog grooming

o It is recommended that the Team decides on a fixed amount of time (e.g., 2 to 5 minutes) to spend on sizing a single story.

o Estimation is performed by doing relative comparison to a baseline story that the team has established





Appendix B

• Meetings specific to Agile There are five meetings that are commonly held during each sprint for an agile project:

1. Daily Scrum a. Purpose: Meet as a team to provide commitments for what will be accomplished during the day. b. Frequency - Daily c. Attendees: Project team, Scrum Master, Product Owner. Other stakeholders may attend, but are not

allowed to talk. d. Agenda

i. What tasks have finished since the last Scrum meeting ii. What tasks will be worked on today

iii. Are there any impediments to completing tasks? e. Notes

i. This is not a status meeting for the Scrum Master ii. Scrum Master facilitates

iii. Time-boxed to 30 minutes iv. Team should update any task and story status before the meeting Not used for problem solving

2. Sprint Planning a. Purpose: Select a goal for the sprint, and create the Sprint Backlog. b. Frequency: Once per sprint on the first day c. Attendees: Project team, Scrum Master, Product Owner, other stakeholders as necessary d. Agenda

i. Select Items from backlog that will be worked on during this sprint ii. Create Sprint Backlog

iii. Perform high level design, including verifying story points, assigning estimates to tasks iv. Team members take responsibility for tasks

3. Sprint Demo a. Purpose: Team demonstrates the functionality that was just completed in this sprint. b. Frequency: once per sprint on the last day c. Attendees: Project team, Scrum Master, Product Owner, other stakeholders d. Agenda

i. Team(s) present work accomplished during the sprint ii. If not already accepted, Product Owner should accept (or reject) stories

e. Notes i. This is an informal meeting ii. Less than 2 hours

iii. Only finished products should be shown – do not create power point slides. iv. Invite any outside parties, other stakeholders that would be interested in results

4. Sprint Retrospective a. Purpose: Reflect on lessons learned in the just-completed sprint b. Frequency: Once per sprint, on the last day c. Attendees: Project team, Scrum Master, Product Owner, other stakeholders





d. Agenda i. What went well ii. What could be improved

iii. What should the team stop doing, start doing, or continue doing iv. Review action items from previous sprints v. Create action items, including assigning responsibilities and due dates

e. Notes i. Scrum Master facilitates the retrospective meeting

5. Managers Meeting (aka Level 1.5)

a. Purpose: This is an optional meeting, and not specific to Agile. Teams can use this time to provide an opportunity for stakeholders that do not participate in the scrums to ask questions, review status.

b. Frequency Weekly c. Attendees: Project Manager, Business Owner, other stakeholders d. Agenda:

i. Project Status ii. Other

iii. Q&A e. Notes: this agenda will vary depending upon the nature of the project. It can be an opportunity to discuss

risks and issues, provide a demo of functionality, and many other topics.

Appendix C

• Agile Project Dashboard As a means of sharing project information, teams should determine the best approach for their projects. Teams need to consider the audience for the information and how often it needs to be updated and reported. Dashboards can be as simple as an Excel spreadsheet, a wiki site, or a combination of tools including the use of Atlassian JIRA. Teams need to be able to manage a Product Backlog, Release Backlog, Sprint Backlogs, Epics/User Stories, Story Points, risks, and impediments.





There are three levels of documentation that should be tracked. Product Backlog The Product Backlog contains the stories for the product/project. It is continually reviewed and updated by the Product Owner. Release Backlog The Release Backlog contains the stories that are in scope for the release. It is continually reviewed and updated by the Product Owner. Sprint Backlog The Sprint Backlog is what is used by a team to track the work being done for a time box (sprint). The Sprint Backlog will contain the stories, tasks, story points, assignee, and the status of the story and tasks. The team should keep this information updated on a daily basis. Project Dashboard Another level of tracking is a project dashboard. This dashboard is a snapshot of progress on the product/project. Information from the teams is used to show progress (product burn up or burn down chart), risks, issues, and impediments.

Revision History Date Version Revision Revised By Status


capability pattern handbook - agile...1.3 roles and responsibilities ... agile development. 1.3.1...

Documents