Attachment J1 - NLS Agile Methodology Guide.docx

bugs

NLS Agile Methodology Guide

Version 2.0 12/01/2022

National Library Service for the Blind and Physically Handicapped The Library of Congress 1291 Taylor Street NW Washington, DC 20542

(202) 707- 5100

Document History

· Agile in a Contract Environment

· Sprint Goal and Task Decomposition

· Responsibility for Acceptance Criteria and Deliverable Description.

· Sprint Team Evaluations

· Unplanned Team Member Changes

Modify some requirements as optionally required.

Update 3.5.2

Contents

1. Introduction

1.1 Purpose

This document describes and defines activities and expectations associated with the Agile methodology used by NLS to complete development projects.

1.2 Glossary of Acronyms

The following acronyms are used throughout the document

2. Agile Methodology

2.1 Agile in a Contract Environment

Due to the nature of government contracting, certain aspects of NLS’s implementation of the Agile methodology may not be consistent with industry standards and best practices. These discrepancies are necessary in order to comply with Library of Congress contract rules and regulations.

2.2 Tools and Products Used

NLS utilizes several tools manage the Agile projects. The deliverables in section X of this document reflect spreadsheet-based artifacts. The task order shall specify which deliverables section applies to the project.

The following tools and products may be used as part of the software development project:

· Microsoft Office product suite

· Git repositories

· Google / Amazon cloud hosting services

· Google Drive

· Docker

· UML Modeling

2.3 Frameworks Used

The contractor shall be familiar with the following frameworks used at NLS as part of the software development lifecycle:

· Eclipse Mars IDE

· Spring IDE

· Rational RSA/Eclipse

· CodeIgniter Web Framework

2.4 General Information

· The contractor shall provide a number of consecutive development cycles per year. A development cycle will be called a Sprint

· Each sprint will involve a fixed number of development hours based on the number of expected full time equivalent (FTE) personnel. See Section 2.6 for details about the expected per sprint hours.

· Hours expended by the scrum master shall be considered part of the fixed sprint hours.

· For more information regarding sprint hours see Section 2.6.

· The first sprint where the sprint artifacts are created shall be referred to as “Sprint 1”. In literature of agile methodology, this first sprint is sometimes referred as “Sprint 0” and sometimes as “Sprint 1”. For the purposes of this contract the first sprint shall be referred to as Sprint 1.

· The NLS COR or his designate shall be the primary point of contact for the NLS team.

· The entire list of initial enhancements or modifications to the system that have yet to be completed will be documented in a group of artifacts called the “baseline artifacts”.

· See Section 2.8 for more information about the baseline artifacts

· See Section 8 for a complete list of project artifacts and associated templates

· The agile methodology requires flexibility in terms of the activities that are performed during each sprint. The contractor is expected to manage the composition of the development team in order to best meet the needs of the development activities that are anticipated to occur.

· For example, during Sprint 1 when the baseline artifacts are to be created, it would be expected that the contractor provide a team well suited for the creation of baseline artifacts, with skills in the area of planning, LOE estimation, system analysis, and design.

· The contractor shall use the NLS provided Google website document repository (or equivalent as agreed on with NLS) and Git code versioning system.

· NLS shall provide the contractor accounts in the NLS federal google applications domain.

· There will be one account provided per contractor staff member.

2.5 General Sprint Activities

Each sprint will involve the following activities:

· The contractor development team shall attend a virtual meeting at least once a week and not more than once a day, unless an alternate schedule is agreed to by COR and the contractor. The meeting shall be led by the contractor scrum master.

· The purpose of this meeting is to coordinate development work and to ensure any problems or obstacles are resolved promptly.

· When a virtual meeting space is needed to share information such as computer screens, Zoom or Skype will used as the virtual meeting space unless an alternative virtual meeting space is agreed to by NLS and the contractor in advance of the meeting

· The contractor development team shall ensure that all contractor personnel have access to computers that have web cams, microphones, or telephone when needed for the purpose of the virtual meetings

· The contractor development team shall be continuously reachable during development activities via email, phone, or Slack, Skype, or Zoom (as needed)

· During the sprint there may be Change Control Board (CCB) meetings. These meetings will be executed using the virtual meeting space or conference call. NLS may require that the scrum master attend.

· Virtual attendance is acceptable.

· The output of the CCB will be a one or more actions, usually approval or rejection of CCB requests.

· These actions may affect an existing PBL item (e.g. exit alpha test and enter beta test), or alter a PBL item (such as change a requirement), or add or remove a PBL item (such as add a new requirement).

· The contractor development team shall perform the necessary work for the numbered sprint according to the Sprint Plan.

· The specific deliverables for the sprint are itemized in the Sprint Plan and must be delivered by the end of the sprint as described in Section 6. At a minimum the contractor must deliver the following items at the end of every sprint:

· Updated release target artifacts (SRS, SRP, PBL, TM, ITTM, ATM).

· Updated baseline artifacts (BSRS, BPBL, and BTM)

· The deliverables required for delivery at the end the sprint are defined in the sprint plan and must be delivered by the end of the sprint as described in Section 6. These deliverables may include:

· Source code, object code, and binaries associated with each and every one of the client and/or server modules of the production-ready system as specified by the sprint deliverable plan.

· Database schema and database migration or initialization scripts as specified by the sprint deliverable plan.

· Software design specifications, configuration files, and configuration tools as specified by the sprint deliverable plan

· Documentation, including user and administrative manuals as specified by the sprint deliverable plan

· Installation or upgrade plans as specified by the sprint deliverable plan.

· Training materials, both administrative and user as specified by the sprint deliverable plan

· Alpha and Beta Testing Plans, results, and associated metrics as specified by the sprint deliverable plan

· Deployment plans as specified by the sprint deliverable plan.

· Disaster recovery plans as specified by the sprint deliverable plan.

· User stories

2.5.1 Role of the Scrum Master

The contractor shall provide one individual who will be the scrum master for the contractor development team. The effort expended by the scrum master is considered developer hours and is to be considered part of the firm fixed price of the sprint.

The scrum master shall:

· Be the primary point of contact for the contractor developer team

· Lead the development of project artifacts, including User Stories, during the appropriate phases of the agile development lifecycle.

· See Section 2.8.1 for more information regarding tasks associated with User Stories

· Coordinate developer activities and creation and maintenance of various artifacts associated with the sprint.

· Be the contractor representative to the appropriate change control board.

· Maintain the baseline documentation artifacts such as Product Backlog, Sprint Plan, and Software Requirements Specifications.

· Prepare CCB requests as appropriate for any issues the contractor deems requiring CCB action and submit the request to the NLS project leads, as may be required by NLS.

· For example, the contractor, as part of their development activities, may realize the need for a new requirement or modification to an existing requirement

· The contractor shall develop any materials associated with the request such as a requirement description

· Maintain the project artifacts, including those approved by the CCB

· These may be the release target artifacts (for CCB actions that affect the release target) or the baseline artifacts (for CCB actions that are outside the scope of the release target).

· Report progress of the sprints during NLS PRB, and QRB meetings

· Ensure continuous integration and continuous development process for each sprint/UC/USTs are implemented

2.6 Clarifications about Sprint Hours

2.6.1 Rationale for Per Sprint Hours

While NLS expects the development resources to be dedicated to the NLS project full-time, NLS understands a certain number of hours are to be expended by the resource for non-NLS administrative activities such as company meetings, required training, vacations, and holidays.

2.6.2 1 FTE Sprint Hours The defined hours per sprint for the equivalent of 1 FTE is 85 hours for a two week sprint and 170 hours for a four week sprint. The contractor shall average the defined hours per sprint over the lifetime of the project. The total hours for an individual sprint shall be no more than plus or minus five percent of the defined sprint and must be approved by the CCB and COR. The contractually-defined per sprint cost does NOT change based on hours deviation from the defined per sprint cost; the per sprint cost is based on 85 hours for a two week sprint or 170 hours for a four week sprint.

2.6.3 2 FTE Sprint Hours The defined hours per sprint are 170 hours for a two week sprint and 340 hours for a four week sprint. The contractor shall average the defined hours per sprint over the lifetime of the project. The total hours for an individual sprint shall be no more than plus or minus five percent of the defined sprint and must be approved by the CCB and COR. The sprint based hours and pricing plan will be agreed on for each task order with the understanding that some tasks and requirements may potentially require less hours, less staff, and potentially shorter sprint cycles.

2.7 Sprint Types

2.7.1 Planning Sprints

The contractor shall utilize a Planning sprint as the first sprint (Sprint 1), and as necessary throughout the project, in order to develop the baseline artifacts as described in Section 2.8.

2.7.2 Development Sprints

Upon completion of the Planning Sprint and approval of the baseline artifacts by the NLS CCB, the contractor shall begin activities defined in the sprint plan for the next sprint.

2.7.2.1 Sprint Goal and Task Decomposition

The goal of each development sprint is for a particular element of system functionality to be 100% complete at the end of the sprint. This functionality can be small, such as a button and its associated action 100% functional or very large such as a section of a website being complete. To accomplish this, requirements and tasks must be broken down to a level sufficient for 100% functionality delivery. In cases where it is not possible for 100% functionality to be achieved in a single sprint the contractor shall provide a report describing the progress made and the remaining tasks or functionality.

2.8 Baseline Artifacts

At the completion of the Planning Sprint (starting with Sprint 1) the contractor shall create and deliver the baseline project artifacts, including:

· Software Requirements Specification (BSRS)

· The contractor shall use the CCB-approved customer requirements and use cases to create the BSRS

· Is a contract deliverable.

· Baseline Product Backlog (BPBL) and Sprint Plan

· The contractor shall use the BSRS to develop the BPBL and Sprint Plan

· The BPBL will include all activities such as design, coding, testing (alpha, beta, and acceptance), documentation, training, and deployment including tasks associated with Sprint 1

· When the BPBL is implemented in full (or ‘consumed’), the resulting system is deemed to have been built, tested, and deployed and will have fulfilled the desired customer requirements.

· The contractor shall provide a good faith estimate of the Level of Effort for each task in the BPBL

· Are contract deliverables

· Baseline Traceability Matrix (BTM)

· The relationship between requirement in the SRS and items in the BPBL may be one- to-one, one-to-many, or many-to-one.

· The BTM ensures that all requirements in the SRS are handled by at least one element in the BPBL.

· The BTM is a contract deliverable.

The contractor may be required to create user stories as part of the baseline artifacts. Section 2.8.1 details the process for completing User Story creation.

For unusually large or complete projects, the creation of the baseline artifacts may take more than one sprint of effort. In these situations, this information will be specified in the task order and two or more sprints may be assigned to the creation of the baseline artifacts.

2.8.1 User Stories Tasks

User Story Tasks If user story creation is included as part of the contract, The Scrum Master shall be responsible for the creation of User Stories, including the following tasks:

· Lead the development of the User Stories

· Work with the contractor development team to complete the User Stories

· Document all User Stories

· Work with NLS Systems Engineer and Subject Matter Experts (SME) to validate USTs

· Dissect each Use Case into the required USTs

· Ensure each UST realizes a feature – capability/function ( in partial or full) of the corresponding UC

· Ensure each UST dissects the specific UC and has a test case

· Coordinate and hold, at-least one demo of the planned UST to the Systems Engineer and SMEs during the lifecycle of each sprint

· If this is not necessary during a particular sprint, the Scrum Master shall notify the project team at the beginning of the sprint If User Stories are assigned to the contractor as part of the contract, the vendor must deliver user stories at the completion of each sprint they are worked on as described in deliverable 4.1.22 in Section 8.

2.9 Development Sprint Artifacts

At a minimum, the contractor must submit the following deliverables at the completion of each sprint:

· Updated Product Backlog (PBL)

· Updated Sprint Plan

· Updated Release Target

· Updated Software Requirements Specification

· Updated Traceability Matrix (TM)

· Updated IT security Traceability Matrix (ITTM)

· Updated Accessibility Traceability Matrix (ATM)

· Updated User Stories (if assigned and applicable) The contractor shall follow the process defined in Section 6 for submitting sprint deliverables.

2.9.1 Responsibility for Acceptance Criteria and Deliverable Description The contractor is responsible for ensuring the deliverable description and acceptance criteria of each item in the Product Backlog and Sprint Plan is accurate. NLS will test and judge the quality of each sprint deliverable based on the deliverable description and acceptance criteria listed in the Sprint Plan.

2.9.1.1 Writing Acceptance Criteria

Acceptance criteria define the boundaries of a user story and are used to confirm when a story is complete and working as intended. Acceptance Criteria shall include how the functionality should work and all expected behavior of the functionality. Acceptance criteria shall be written in the following format:

· Scenario: Situation to be tested

· Given: Precondition

· When: Action by the user

· Then: Testable outcome achieved Example acceptance criteria:

· Scenario: The user is about to log in, but, needs instructions on resetting password

· GIVEN a user looking at the login page,

· WHEN the user wants to get password help

· THEN the application will already be displaying a link to get instructions to do this

2.10 Release Targets

NLS staff, in consultation with the contractor development team, will identify a list of one or more backlog items selected from the baseline for implementation. This group of backlog items selected for implementation becomes a Release Target.

· The list will be chosen based on what development order makes the most sense, what can be accomplished successfully during the sprint timeframe, and what items are best grouped.

· The Release Target list of product backlog items may be a subset of the BPBL or it may be the entire PBPL.

· As part of the definition of the Release Target, the number of sprints will be identified that will be necessary to accomplish the release target.

· Will be refined in the Sprint Plan.

· The contractor development team shall create the appropriate CCB action requests for the NLS CCB in order to obtain CCB approval to proceed with the implementation of the Release Target.

· Will be described in the following section

2.10.1 Release Target Artifacts

As part of the Release Target development process the contractor shall create:

· Software Requirements Specification (RT-SRS) for the Release Target

· Based on the list of backlog items included in the Release Target

· May be a subset of the BSRS or the entire BSRS

· Is a contract deliverable.

· Product Backlog (RT-PBL) for the Release Target

· May be a subset of the BPBL or the entire BPBL

· Is a contract deliverable.

· Sprint Release Plan (SRP) for the Release Target

· Based on the RT-PBL.

· Will map out the number of sprints that will be needed to eliminate the backlog, what needs to occur in each sprint, and it will itemize the specific deliverables that are to be delivered at the conclusion of each sprint.

· The SRP for the release target is a contract deliverable.

· Traceability Matrix for the Release Target (RT-TM)

· The relationships may be one- to-one, one-to-many, or many-to-one. The BTM ensures that all requirements in the SRS are handled by at least one element in the PBL.

· Is a contract deliverable.

· IT Security Traceability Matrix (ITTM)

· Ensures the appropriate security controls are handled as part of the development activities for each item in the PBL

· A PBL item may be affected by no security controls or by multiple security controls

· The list of security controls is the list of IT security controls identified in the NLS A&A package that are applicable to the application

· All test plans are expected to use the ITTM in order to test IT security

· Is a contract deliverable.

· Accessibility Traceability Matrix (ATM).

· Ensures the appropriate accessibility accommodations are handled as part of the development for each item in the PBL

· A PBL item may be affected by no accessibility requirements or by multiple accessiblity requirements

· All test plans are expected to use the ATM in order to test for accessibility

· Is a contract deliverable.

2.11 Sprint Time Period Exception

· The contractor shall execute the required number of developer hours per sprint within the agreed upon sprint timeframe which is two weeks or four weeks.

· The contractor or NLS may request an alteration (either a shortening or a lengthening) of the sprint timeframe in order to accommodate contractor or NLS personnel schedule interruptions such as vacations.

· Alterations may not exceed plus or minus 50% of the nominal sprint timeframe.

· Requests for these alterations must be made prior to the start of the sprint.

· Alterations must be done in such a manner that even with the sprint time frame alterations, the allotted task order sprints are completed within the period of performance 12 consecutive sprints can be executed during a calendar year.

· Alterations must be approved by the COR

3. Development Activity Oversight

3.1 General Information

· The contractor shall manage all development activities in a manner consistent with the System Development Life Cycle (SDLC) process recommended by the Library of Congress.

· The SDLC will govern the management processes associated with the development of the project.

· Tracking and oversight of the project would be complemented by corresponding integrated planning and quality reviews.

· There will be three oversight boards:

· The NLS Change Control Board (CCB) will have overall responsibility for approving the content and quality of each Sprint

· The NLS planning review board (PRB) will have overall responsibility making recommendations to the CCB to accept/reject sprint artifacts and planning decisions

· The NLS quality review board (QRB) will have overall responsibility for making recommendations to the CCB to accept/reject content and quality of each iteration

· NLS may requires that the contractor Scrum Master shall lead PRB and QRB meetings

· Agile development team stakeholders/participants are as follows:

Key= PM: Project Manager; SM= Scrum Master

PRB

per iteration

Development team

2x/week or more

via QRB meeting

3.2 Sprint Team Evaluations

Within two weeks of the conclusion of every 3 month period NLS shall conduct and provide the contractor with a performance evaluation, using an evaluation template approved by the Library of Congress Office of Contracts and Grants Management. In the event the contractor receives lower than “satisfactory” rating on a single category, the contractor shall have the opportunity to discuss the rating with NLS and rectify the problem if necessary. Should a contractor successfully correct the problems described in the performance evaluation, NLS shall conduct and provide an updated evaluation for the sprint.

3.3 Team Skills and Knowledge

The makeup of the skills and knowledge required by the project team may change during the life of the project. The sprint plan shall determine the mix of skills and knowledge required for any one sprint. While NLS expects the skills and knowledge required to be consistent throughout the project, there may be times when tasks require very specific skills or knowledge in order to be completed.

3.3.1 Scrum Master Requirements

To help ensure a successful project, NLS requires the Scrum Master to have significant experience in the following areas:

1. The Scrum master must have significant experience and demonstrable abilities working with agile development team as follows:

· Facilitating (not participating in) the daily standup

· Helping the Scrum Team maintain their product backlog

· Setting up retrospectives, sprint reviews, and sprint planning sessions

· Shielding the team from interruptions during the sprint

2. The Scrum master must have significant experience and demonstrable abilities working with product owner's SMEs and stakeholders

· Walking the product owner through technical user stories

· Encouraging collaboration between the Scrum Team and product owner

· Assisting the Scrum Team in estimating the effort required to complete the tasks agreed to for the Sprint

· Removing obstacles that affect the team

3.4 Unplanned Team Member Changes

In the event the contractor makes a change to the team (replacing a team member or adding a team member) without proper notification to NLS or causes undue harm to the project, the hours associated with bringing the new team member “up to speed” on the project shall not be counted towards the sprint hours.

3.5 Definition of Bugs and Defects

NLS recognizes that some types of bugs are normal as part of the development process but there are situations in which bugs are not to be expected and will not be tolerated in any form or fashion.

3.5.1 Acceptable Bugs

NLS understands that certain types of bugs will occur as part of the development process and are considered normal should they occur. These types of bugs include:

· Unforeseen workflow errors

· Bugs resulting from complex mathematical calculations These bugs are considered acceptable in the sense that they will be handled in future sprints with the hours consumed to fix the bug coming from the 10% contingency hours in the sprint.

3.5.2 Unacceptable Bug

Certain types of issues and bugs are unacceptable and will result in rejection of the sprint by the project team and CCB pursuant to Section 7.1. These types of bugs include:

· Bugs that are the result of inadequate programming skills such as:

· Not properly checking for errors

· Failure to design web systems using modern web design methodologies

· Consistently verifiable bugs in release builds that disallow normal operations of the applications.

· Bugs and poor performance and issues as monitored by performance monitoring software. Contractor must monitor performance monitoring software (example: Sentry) events and take responsibility for bugs and major performance degradation as automatically reported.

4. Communication during Sprints

4.1 Sprint 1 and other Planning Sprints

The contractor is responsible for developing the baseline sprint artifacts during Sprint 1. In order to maximize the probability for success, the contractor shall:

· Maintain regular communication with NLS consistent with processes and procedures as set forth in Section 3 of this document

· As may be optionally required by NLS, attend weekly schedule PRB and QRB meetings (in person or virtually)

· Provide status and incremental artifacts to PRB eight (8) business hours before each weekly schedule meeting.

· The PRB will provide formal feedback whether artifacts are in line with NLS expectations and requirements.

NLS shall:

· Make a good faith effort to provide necessary explanation and detail for all contractor questions to respond within contractor’s four (4) business hours, with an understanding that communications with NLS staff is expedited through Library of Congress’s Slack, Skype, or Zoom communication channels.

· Provide an agenda for all weekly schedule PRB and QRB meetings within eight (8) business hours of the start of each meeting unless previously established

4.2 Development Sprints

The contractor shall:

· Maintain regular communication with NLS consistent with processes and procedures as set forth in section C.3.1 of this document. The contractor shall make a good faith effort to communicate on a regular basis, preferably twice weekly, with NLS regarding the progress of sprint deliverables.

· As may be optionally required by NLS: Attend all weekly schedule PRB and QRB meetings (in person or virtually)

· As may be optionally required by NLS: Attend CCB meetings (in person or virtually)

· Provide status and updated artifacts to PRB and QRB eight (8) business hours before each weekly schedule meeting. The PRB will provide formal feedback whether artifacts are in line with NLS expectations and requirements.

5. Sprint Transitions

5.1 Transition from Planning Sprints to Development Sprints

5.1.1 During the Sprint

· At the beginning of the sprint the contractor is responsible for clarifying any questions about the actual content of the deliverables as well as clarifying any questions about the method used to deliver the deliverables.

· During the sprint, the contractor shall be providing frequent status updates to NLS regarding the status of the deliverables. At a minimum this feedback will occur during the PRB meetings. Other feedback sessions may include daily scrum meetings.

· All required artifacts to be reviewed by the PRB must be sent to the PRB meeting facilitator at least eight (8) business hours before each weekly schedule meeting. The PRB will provide formal feedback whether artifacts are in line with NLS expectations and requirements.

· The updates and feedback from NLS are used to ensure the deliverables will be of satisfactory quality

· The contractor is solely responsible for the content and quality of the deliverables

5.1.2 Upon Sprint Completion

· At the conclusion of the sprint, the contractor shall deliver the sprint deliverables by the agreed upon delivery method as defined in Section 6.

· The contractor may not begin work on the next sprint until the CCB has approved the sprint artifacts

· The NLS PRB will then assess the quality of the deliverables.

· If acceptable the PRB will then recommend to the CCB that the deliverables should be accepted

· If not acceptable (there is a deficiency) then the contractor will be notified (the scrum master sits on the PRB so notification is instant) and the remediation procedure described in section 7.1 will be invoked.

5.2 Transition between Development Sprints

5.2.1 During the Sprint

· At the beginning of the sprint the contractor is responsible for clarifying any questions about the actual content of the deliverables as well as clarifying any questions about the method used to deliver the deliverables.

· During the sprint, the contractor shall be providing frequent status updates to NLS regarding the status of the deliverables. At a minimum this feedback will occur during the PRB meetings. Other feedback sessions may include daily scrum meetings.

· The deliverables of each development sprint are defined by the CCB-approved baseline artifacts.

· All required artifacts to be reviewed by the PRB must be sent to the PRB eight (8) business hours before each weekly schedule meeting. The PRB will provide formal feedback whether artifacts are in line with NLS expectations and requirements.

· The updates and feedback from NLS are used to ensure the deliverables will be of satisfactory quality

· The contractor is solely responsible for the content and quality of the deliverables

5.2.2 Upon Sprint Completion

· At the conclusion of the sprint, the contractor shall deliver the sprint deliverables by the agreed upon delivery method as defined in Section 6.

· The contractor may then begin work on the next approved sprint as defined in the approved sprint plan so long as the conditions defined in Section 5.3 are met.

· The NLS QRB will then assess the quality of the deliverables.

· If acceptable the QRB will then recommend to the CCB that the deliverables should be accepted

· If not acceptable, the contractor will be notified (the scrum master sits on the QRB so notification is instant) and the remediation procedure described in section 7.1 will be invoked.

· Work on the current sprint may be interrupted while remediation is underway.

· Per the procedure in section 7.1 this work will not be billable (meaning considered part of the current sprint) if the defect is attributed to contractor performance.

· If the deliverables are recommended for approval by the QRB, a CCB meeting will occur and a formal vote on the deliverables will be conducted and a disposition record will be generated

· The disposition record will be sent to the contractor

5.3 Allowable Outstanding Sprints

The contractor shall not have more than two outstanding completed and delivered sprint which has not been CCB approved at any given time. In the event the contractor completes and delivers a second sprint before the first outstanding sprint is approved by the CCB, the contractor shall immediately stop work until the first outstanding sprint is approved by the CCB. The contractor may request the COR grant approval for the contractor to continue work. However, the contractor does so at their own risk and work completed in these situations is not guaranteed to be funded or approved.

As an example, Contractor XYZ has delivered development Sprint 19 to NLS and has started work on development Sprint 20. Contractor XYZ shall not start work on development Sprint 21 until development Sprint 19 is CCB approved.

5.3.1 Rationale for this Policy

It has been the experience of NLS when teams are allowed to have more than two completed sprints outstanding, the risk increases greatly. This is because sprint work typically builds upon work completed in the previous sprint; if the previous sprint work has not been approved there is a risk the contractor is building upon incorrect or unsatisfactory work. By allowing the contractor continually build upon unapproved work, the risk posed to NLS becomes too great. Additionally, because the sprint deliverables include an updated sprint plan, by having too many sprints outstanding the team may be completing work against a sprint plan that no longer reflects the priorities of the project stakeholders.

5.3.2 Exceptions to this Policy

There are two situations in which this policy either does not apply or the number of outstanding sprints changes: teams completing approved parallel sprints and multiple development teams working under the same project.

5.3.2.1 Approved Parallel Sprints

In cases in which the COR has approved the contractor to work in parallel sprints, the number of outstanding sprints allowed double the number sprints being worked on in parallel. Meaning:

· If a team works on 2 sprints in parallel, they can have no more than 4 sprints outstanding

· If a team works on 3 sprints in parallel, they can have no more than 6 sprints outstanding

· If a team works on 4 sprints in parallel, they can have no more than 8 sprints outstanding

5.3.2.2 Multiple Teams under Same Project

For contracts in which the contractor has multiple teams working on a project, each team is limited to two outstanding sprints at one time. Meaning Team A and Team B can each have two outstanding sprints before they must stop.

6. Submission of Sprint Deliverables

6.1 Notification of Sprint Deliverables

By 11:59 p.m. ET of the date defined as the sprint end date the sprint plan, the Scrum Master or Project Manager shall notify the NLS Digital Projects Coordinator and the contract COR of sprint completion via email. The notification email shall include:

· Statement affirming completion of the sprint

· List of tasks completed

· List of tasks not completed and reason for not completing the tasks (if applicable)

· All sprint deliverables as defined in the sprint plan submitted either as attachments in the email or a link to a single file (usually a .zip file) in a shared location as agreed to by NLS and the sprint team in the email In the event the email system is not available to submit the notification email, the Scrum Master or Project Manager will notify the NLS Digital Projects Coordinator via telephone of the email delivery problem. A sprint is not considered completed until the notification email is received by NLS.

Note: completion of the sprint does not constitute acceptance of the sprint by NLS; only the NLS Change Control Board (CCB) and COR can accept the sprint deliverables.

6.1.1 Submission of Source Code

For sprints where code is developed as part of the sprint, the contractor shall submit the source code as part of the sprint deliverables package. The source code can either be the entire application source code or only the source code developed during the sprint. The source code files must clearly show the date of completion. This can be accomplished via comments in the source code or in the file information.

6.2 Requesting Extensions to Notification Due Date

In the event the sprint team Scrum Master or Project Manager is unable to submit the notification of sprint completion as defined in Section 6.1, a request for extension must be made to the NLS Automation Digital Project Coordinator and contract COR via email. The request must be made no later than 5:00 p.m. of the end date of the sprint. The maximum allowable extension for notification of sprint completion is 5 business days.

6.3. Failure to Submit Sprint Deliverables

In the event a sprint team does not submit notification and associated deliverables to the NLS Automation Digital Project Coordinator as defined in Section 6.1, the remediation process as defined in the contract shall be invoked and the contractor is not authorized to work on activities associated with the next sprint. Any hours expended without authorization to work will be considered non-billable and will not be paid for by NLS.

7. Sprint/Release Target Failures

7.1 Failure to Meet Sprint Deliverables

· The contractor shall meet the deliverable schedule and quality level for the sprint that are identified during the sprint backlog by the conclusion of the sprint.

· Should the contractor be unable to meet deliverable schedule and quality level for the sprint, a remediation phase is to be engaged.

· The COR or his designate will notify the contractor in writing of the failure to meet the sprint deliverable schedule or quality standards. Upon receipt, the contractor has the option to request a review of the issue with the contracting Officer or to develop a plan to achieve the deliverables and quality level during an additional period of time after the sprint ends.

· This period of time is not to exceed 50% of the sprint timeframe and shall be done at no cost to the government.

· Three consecutive sprint failures of deliverable schedule and quality level will be considered grounds for the government to terminate the development portion of the contract and stop all further sprints. This will take the form of the government not executing any further options on the sprints.

7.2 Failure to Accomplish Release Target Objectives

· The contractor shall make a good faith effort to staff the development team with individuals who have the necessary skills, experience, and aptitudes to accomplish the objectives of the sprint backlog.

· The contractor shall make work estimates and shall develop the sprint backlog plan in good faith in order to achieve the release target objectives.

· At the end of any sprint, should the COR or his designate believe that the contractor is not acting in good faith in regards to these issues or that the contractor is not capable of achieving the release target objectives, the COR or his designate shall notify the contractor in writing of this within two weeks of the end of the sprint, providing appropriate evidence.

· Upon receipt, the contractor has the right to request a review of the notice by the contractor, the COR, and government contracting officer. The contractor has the option to develop a remediation plan to overcome the issues identified by the COR. The remediation plan may include additional or a change in development team staffing or alterations of duties.

· Three written notices to the contractor on three sprints during the course of one year will be considered grounds for the government to terminate the development portion of the contract and stop all further sprints.

· This will take the form of the government not executing any further options on the sprints.

8. Contract Deliverables

8.1 Spreadsheet-based Deliverables

The following templates are provided as a guide for contractors use as during the contract and are required to be delivered as defined in the contract,

Updated version submitted at conclusion of every sprint starting with sprint 2.

· 901A - Baseline Software Requirements Specification Template.xlsx

( https://drive.google.com/open?id=0B0DoPqUwPNWeQk9yZ2ZnVmNCTzA)

OR

· 901B - Baseline Software Requirements Specifications Template.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeam1LLUowenFnX1k )

0901C - How_To-Baseline_SRS_Excel.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeMXpxQ2phX2hzX2c )

Updated version submitted at conclusion of every sprint starting with sprint 2.

· 902A - Backlog Sprint Plan and Release Target Template.xlsx

( https://drive.google.com/open?id=0B0DoPqUwPNWeMTY0VUdXYXdrNzQ)

OR

· 902B - Backlog Sprint Plan and Release Target Template Automated.xlsx

(https://drive.google.com/file/d/0B0DoPqUwPNWeOEFXOFBKWHNvSmM)

0902C - How_To-Product_Backlog_Sprint_Plan.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeT2luck1TdWxCY3c )

Updated version submitted at conclusion of every sprint starting with sprint 2.

(https://drive.google.com/open?id=0B0DoPqUwPNWeT2luck1TdWxCY3c )

0902D - How_To-Estimate-LOE.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeSExFalN3QUJwX28)

Completion of Req. Traceability Matrix, Acc. Traceability Matrix (ATM), Sec. Traceability Matrix (ITTM) tabs in 0901A - Baseline Software Requirements Specifications Template.xlsx

(https://drive.google.com/open?id=0B0DoPqUwPNWeQk9yZ2ZnVmNCTzA )

OR

Completion of section 4. Appendix of 0901B - Baseline Software Requirements Specifications Template.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeam1LLUowenFnX1k )

0901C - How_To-Baseline_SRS_Excel.docx

(https://drive.google.com/open?id=0B0DoPqUwPNWeMXpxQ2phX2hzX2c )

(https://drive.google.com/open?id=0B0DoPqUwPNWeUS1aNms4eGQxc2s )

Submission to NLS Automation Digital Project Coordinator

Updated version submitted at conclusion of every sprint starting with sprint 2.

Completion of Release Targets tab in one of the templates listed in 3.1.3

Completion of 0905 – Release_Notes Template.docx

( https://drive.google.com/open?id=0B0DoPqUwPNWedjF0Z09QSEw4WEE)

Not applicable

Updated at conclusion of the first subsequent sprint following completion of all items in the current release target.

Updated at conclusion of the first subsequent sprint following completion of all items in the current release target.

Updated at conclusion of the first subsequent sprint following completion of all items in the current release target.

Updated at conclusion of the first subsequent sprint following completion of all items in the current release target.

As needed as bug fixes are identified which require system modifications or enhancements to resolve Completion of 903 - CCB_Request_Template.docx

( https://drive.google.com/open?id=0B0DoPqUwPNWeUS1aNms4eGQxc2s)

Submission to NLS Automation Digital Project Coordinator

( https://drive.google.com/open?id=0B0DoPqUwPNWeU3h6Y0wyZGZINm8)

Alpha Test Results: 0908 – Alpha Test Results Template.docx…