ATT J - Fixed Price Story Point Process.pdf

ATTACHMENT J

NASA CONSOLIDATED APPLICATIONS AND

PLATFORM SERVICES (NCAPS)

FIXED PRICE STORY POINT PROCESS

RFP 80TECH23R0002

CONTRACT #TBD

DATE: MARCH 2023

NCAPS Contract –80TECH23R0002 Attachment J Fixed Price Story Point Process

1. Incremental Development Unit Process

1.1. Incremental Development Unit

An Incremental Development Unit (IDU) is a fixed cycle of development that includes all required support (e.g., requirements gathering, project management, testing support, software development, business analysis, and documentation) associated with delivery of a software product and is expected to target 10 story points per IDU based on the reference user stories defined below.

The Service Customer (SC) remains the entity responsible for prioritizing the IDU backlog, while the contractor is responsible to ensure the unit is adequately filled with the correct number of stories and associated story points (excluding fixes of inoperable functionality, subtasks, and impediments). Fixes for inoperable are handled as part of Application O&M and not included in IDU story points. An Iteration is a two-calendar week period of development, unless a deviation is approved by the Technical Monitor (TM), made up of 1 or more IDUs. Iterations are ordered based on the planned number of story points at their start, and a planned Iteration must be no more than 3 story points below the target to be adequately filled.

The number of IDUs invoiced for an Iteration shall be based on the number of TM approved story points fully completed and accepted by the SC and TM. Delivery of an Iteration requires a minimum of 90% of the planned story points to be fully complete, and partially complete user stories cannot be included. Development Project Start Up and Close Down activities are also not included as part of an Iteration.

The reference user stories below include the full scope of tasks required to deliver the functionality to the SC in a production ready state. Examples of tasks necessary to develop the functionality of a single story include but are not limited to the following:

1.1.1. Discuss requirement details and story points with the Government.

1.1.2. Develop any database tables and relationships relevant to the story.

1.1.3. Develop any models supporting a Model View Controller (MVC) framework.

1.1.4. Develop any business logic, repositories, or model managers supporting the model(s).

1.1.5. Develop controllers to assist with model presentation.

1.1.6. Develop views, supporting view logic, UI interactions and animations.

1.1.7. Adding the same feature to all of the existing views in an application.

User Stories are evaluated by having the contractor match the new story with the closest reference user story below based on scope. Once a match is made, the contractor reviews the scope of the reference user story and makes a determination of the relative complexity compared to the new user story scope. User stories can only be assigned story points from the following scale:

Story Point Scale

The contractor can recommend that the points assigned to the user story be upgraded or downgraded, based on differences in complexity and level of effort. Upgrades and downgrades can only move two levels on the story point scale above. Examples of reasons for upgrading the complexity include extensive repetition of a task and issues that make the functionality difficult to implement, such as entity relationships with significantly more complexity than the reference user story. Stories that are less complex would merit a reduction in points due to the reduction in level of effort. For each user story evaluated, the contractor must provide documentation to the TM for which reference user story was chosen and include a rationale when upgrading or downgrading assigned points.

User story point determinations will be reviewed by the TM or designee when the stories are collected into a proposed IDU. If the TM or designee does not agree with the proposed reference user story or the point value used, the contractor will provide relevant documentation and rationale to support their position. Should the TM and the contractor not come to an agreement, the final decision on story point evaluations belongs exclusively to the Government.

IDUs are scaled to meet the needs of larger development efforts by increasing the number of target points planned and IDUs being consumed concurrently in a fixed cycle. For example, an IDU produces 10 points and consumes one unit. An Iteration with 60 planned story points would consume six IDUs. Additionally, a 13-point story could be combined with a 5-point story to form an Iteration of two units, as 18 points would be within 3 points of the 20-point target. Iterations are managed as a single unit for requirements, planning, delivery, and metrics purposes.

In rare circumstances there is functionality that has an extremely high degree of uncertainty in the implementation solution and warrants marking a story as Investigational. All of the following conditions must be satisfied to mark a story as Investigational:

• The Government agrees there is too much uncertainty in how the functionality can be implemented.

• The acceptance criteria for the investigational story are clearly defined and agreed to by the Government.

• The Acceptance Criteria has requirements to show evidence that a good attempt was made to implement the functionality.

• Approval has been obtained from the COR or their delegate prior to starting work.

• Follow on stories may receive a reduced number of points if work done under an investigational story is used to complete work on another story.

1.2. Startup and Close Down

The development project startup and close downsize is based on the projected number of IDUs consumed by the development project. Large project startups and close downs are required when the projected number of IDUs in the Investigation Report is greater than or equal to 30. Medium startups and close downs are required when the projected IDUs are less than 30, and the IDU is not an Enhancement IDU. Small startups and close downs are not based on the number of IDUs and are implemented for development projects built on COTS platforms that support custom extensions. Currently, these platforms include Maximo, Sitecore, WordPress, Atlassian products and SharePoint.

1.3. Software Change Requests (SCRs) and Enhancement IDUs

Software Change Requests have two different types, those that address inoperable functionality and those that are enhancements to existing functionality. SCRs that request resolution of inoperable functionality are non-story point earning, prioritized by the NCAPS contractor, and worked as part of the Application O&M Bundled Service. SCRs that are enhancements to existing functionality require the disposition of a Change Control Board (CCB). All Enhancement SCRs regardless of Government CCB participation must be decomposed into user stories using the process described above and added to an Enhancement IDU that is prioritized in the Integrated Development Backlog.

Enhancement IDUs are typically efforts that consume four IDUs or fewer (independent of scaling) towards the modification of a single application or system. These IDUs have the same requirements as a regular IDU, are typically composed of stories from multiple SCRs and may be related to multiple applications or systems. Enhancement IDUs require an Investigation Request and a Startup and Closedown if the development project is planned to consume more than 4 IDUs towards the modification of a single application or system. Otherwise, Enhancement IDUs are not large enough efforts to require Investigation Requests or Startup and Closedowns. If the number of IDUs needed for an Enhancement to a single application increases to 5 or more after development work starts then a Startup and Closedown is not ordered as the starting work was not estimated to be over 4 IDUs.

NCAPS Contract – 80TECH23R0002 Attachment J

1.4. Reference User Stories

The following defines the reference user stories and their associated story point values that will be used during the development process to standardize the estimation and consistency of IDU planning. Development on standardized platforms would generally receive a reduction on points due to decease in complex then would be on a fully customized solution.

SharePoint, Maximo, WordPress, and ColdFusion development will utilize the Platform Standardized Point values for the reference stories.

Story Number Reference User Stories Assumptions

Platform Standardized

Points

Non-Platform Standardized

Points

1. As an application user, I need to attach various file types to my data records.

Includes the ability to add/remove attachments to an application record.

Restrictions on types of attachments should focus on file types that create vulnerability concerns.

If the framework for file attachment already exists and is being reutilized this would merit a decrease in complexity.

5 5

2.

As an application user, I need to be able to search and retrieve record data from an external authoritative source for use with my data records.

Service calls are implemented through the Government approved API Management Solution.

May include searching and retrieving records data between Maximo applications or SharePoint Site Collections.

If the framework for API management already exists and is being reutilized this would merit a decrease in complexity.

5 8

Platform Standardized

Points

Non-Platform Standardized

Points

3.

As an application user, I need to be able to create, read, update, delete (CRUD), or archive existing records comprised of data elements necessary to meet organizational business needs.

Includes the ability to modify data fields within an existing record and the ability to CRUD an entire context specific record or form.

Archived data records would have the same function as deleted data records without removing the data from the application.

8 13

4.

As an application user, I need the application to display calculated or derived summary information for the data record upon which user focus has been placed.

Includes items such as pop-ups, nav menu changes, graphical alignments, and icon changes. 1 3

5.

As an application user, I need to be able to create new data records based on my organization’s existing data records.

Includes the ability to clone/copy existing records data to create a new record.

User would be able to modify the cloned/copied record data before saving the new record.

8 8

6.

As an application user, I need the application to maintain a history of my organization's record data changes, including who performed them.

Includes an audit feature that maintains a history of changes to a record and a search and view capability for those records.

8 13

Platform Standardized

Points

Non-Platform Standardized

Points

7.

As an application user, I need to be able to export search results or a filtered set of data to a pre-defined file format or interface for use outside of the application.

Includes a table formatted export of search results data to commonly used files formats (e.g., Excel, PDF, Word).

Results on predeveloped views or pre-filtered data would receive a reduced point value.

Does not include the ability to provide a digital signature.

5 13

8.

As an application user, I need to edit multiple organizational data records in a single transaction. Includes the ability to select one or many records at a time and perform changes to all of the selected records at once.

The changes that can be made would be limited to one data field or value. (e.g., Status Changes or Archiving Records) Does not include changing values of multiple data fields.

5 8

9.

As an application user, when creating a new record, I need the list of possible values from which I can select to be derived from a list of values I maintain in the application.

Includes linking a select list data field with a list of records that already exist.

Does not include implementation of the existing record creation functionality.

If this select list is used in more than one form the additional select list would receive a reduced point value.

1 3

10.

As an application user, I need a user specific dashboard that presents organization record data and application functionality.

Includes the creation of a dashboard page that recognizes the current user, displays record data, and application functionality associated with the user and their role.

Does not include custom, user- specific orientation of dashboard elements or maintaining preferences. May include a custom application layout and application branding.

1 3

Platform Standardized

Points

Non-Platform Standardized

Points

11.

As an application user, I need to search for my organization’s records using one or a combination of many data record elements.

Includes a screen that contains multiple list driven fields from which a database search can be executed using the provided values. May include text fields that provide search terms matching potential values.

5 13

12.

As an application user, I need to filter and sort a list of my organizations data records based on static subset record data.

Includes toggleable sort functionality commonly found in column header fields and basic conditional filters. (e.g., Active

vs. Inactive records)

1 3

13.

As an application user, I need to be notified via e- mail when pre-defined condition is satisfied by the data records captured within the application.

Includes a static formatted e-mail that will be distributed to one or many recipients and logic to determine which recipients will receive the email message.

Does not include maintenance of a list of recipients.

The email framework does not exist, and subsequent use of an established email framework would receive a reduced point value.

3 13

14.

As an application user, I need a set of data attributes displayed on an application screen.

Includes an aggregated display of application data.

May be a SharePoint web part or display of Maximo attributes.

Does not include implementation of the existing record creation functionality.

3 8

Platform Standardized

Points

Non-Platform Standardized

Points

15. As an application user, I need a procedural workflow to act on a data record.

Includes software/code-based development of a workflow.

Low/No code solutions for workflow would receive a reduced point value.

3 8

16.

As an application user, I need an updated user interface to modify the look and feel of my application

Includes mockups, implementation of UI mockup, development of common templates, and page redesigns

3 3

17.

As an application user I need a static change to my website to update text or graphics

Includes static text or graphics changes that occur during the Iteration.

The scaling for this could be increased with a higher number of changes or the complexity of the updated graphic.

Does not include static text or graphics changes associated with Application O&M.

1 1

18.

As an application stakeholder, I need to update common components and infrastructure tooling.

Includes changes to common components supporting the application, such as modifications to project foundation, backend or supporting data services.

Significant software development efforts made to modify reporting tools

8 8

19.

As an application user I need access to the data from my prior system(s), available in my new application.

Includes migration and transformation of existing data or establishing view functionality for multiple data sets.

8 8

20.

As an application user, I need a process to run off hours, and take some action on my behalf.

Includes bulk emails, any process time configuration, database updates, or data loads.

8 8

Attachment J

2. Incremental Team Unit Process

2.1. Incremental Team Unit

An Incremental Team Unit (ITU) is a fixed cycle of development that includes all required support (e.g., requirements gathering, project management, testing support, software development, business analysis, and documentation) associated with delivery of a software product and is expected to target 4 story points per ITU.

The Service Customer (SC) remains the entity responsible for prioritizing the ITU backlog, while the contractor is responsible to ensure the unit is adequately filled with the correct number of stories and associated story points. An Iteration is a two-calendar week period of development, unless a deviation is approved by the TM, made up of 1 or more ITUs. Iterations are ordered based on the planned number of story points at their start, and a planned Iteration must be less than the minimum to be adequately filled.

The number of ITUs invoiced for an Iteration shall be based on the number of TM approved story points fully completed and accepted by the SC and TM. Delivery of an Iteration requires the minimum ordered story points to be fully complete, and partially complete user stories cannot be included.

User story point determinations will be reviewed by the TM or designee when the stories are collected into a proposed ITU. If the TM or designee does not agree with the proposed reference user story or the point value used, the contractor will provide relevant documentation and rationale to support their position. Should the TM and the contractor not come to an agreement, the final decision on story point evaluations belongs exclusively to the Government.

ITUs are scaled to meet the needs of larger development efforts by increasing the number of target points planned and ITUs being consumed concurrently in a fixed cycle. For example, an ITU produces 4 points and consumes one unit. An Iteration with 60 planned story points would consume 15 ITUs. Additionally, a 13-point story could be combined with an 8-point story to form an Iteration of 5 units, as 21 points would be 1 point over the 20-point target. Iterations are managed as a single unit for requirements, planning, delivery, and metrics purposes.

In rare circumstances there is functionality that has an extremely high degree of uncertainty in the implementation solution and warrants marking a story as Investigational. All of the following conditions must be satisfied to mark a story as Investigational.

• The Government agrees there is too much uncertainty in how the functionality can be implemented.

• The acceptance criteria for the investigational story are clearly defined and agreed to by the Government.

• The Acceptance Criteria has requirements to show evidence that a good attempt was made to implement the functionality.

• Follow on stories may receive a reduced number of points if work done under an investigational story is used to complete work on another story.

Attachment J

Program Increment (PI) Planning activities during Government initiated PI events shall be assigned 1 point per day for each ITUs that are actively being worked.

2.2. Software Change Requests (SCRs)

Software Change Requests have two different types, those that address inoperable functionality and those that are enhancements to existing functionality. SCRs that request resolution of inoperable functionality are prioritized by the NCAPS contractor. SCRs that are enhancements to existing functionality require the disposition of a Change Control Board (CCB). All Enhancement SCRs regardless of Government CCB participation must be decomposed into user stories using the process described above and added to an ITU that is prioritized in the Integrated Development Backlog.