The three key steps of the Development phase are described in further detail below.

1. Release Planning

Defining a road map for incrementally releasing meaningful, working pieces of the system.

Using the Product Vision and Story Map as a starting point, business owners define releases. Typically, a “release” is defined as a move to a production environment, though, depending on the nature of the work, a staging environment may be preferable. Teams should confer with the Office of Environmental Information (OEI) to decide on the hosting environment; OEI will assess whether a secure, reliable, cost-effective Cloud option exists for the application. Releases should be defined by the outcome or goal the project team hopes to achieve with the release (e.g., allowing users to download data).

All epics and user stories required to achieve that outcome should be grouped within the release and prioritized using the “weighted shortest job first” approach. This approach ensures that, within a release, stories that deliver the most value with the lowest level of effort and in the least amount of time are built in earlier iterations within a release. These decisions are reflected in the release backlog, which is created in preparation for the first iteration toward a release.

During backlog creation, the project team identifies common system architecture requirements. The elaborated system architecture is collaboratively managed with the Chief Architect or the Chief Architect’s delegates to ensure the system is developed to function within the overall EPA Enterprise Architecture. Teams follow an emergent architecture process so that system needs are documented and delivered “just in time”, to ensure alignment across teams and within the larger enterprise architecture framework.

Deliverables

• Definition of Done: A checklist of the types of work the team is expected to successfully complete by the end of the release, before its work can be declared potentially shippable. A bare-minimum definition of done should yield a complete slice of the product functionality, one that has been designed, built, integrated, tested and documented; it should also deliver validated customer value.
• Release Backlog: The repository for all upcoming work planned for a given release.
• Acceptance Criteria: Identifies the conditions that a software product must satisfy to be accepted by a user, customer or in the case of system level functionality, the consuming system. The acceptance criteria is a set of statements, each with a clear pass/fail result, that specifies both the functional and non-functional requirements and is applicable at the epic, feature and story levels. Acceptance criteria statements constitute our definition of done.
• User Stories: User stories represent epics broken down in to manageable components that may be built in an iteration. They are typically descriptions consisting of one or more sentences in the everyday jargon of the end user that capture what a user does or needs to do as part of his or her job function). For the first iteration of a release to begin, all user stories must be completed and placed in the release backlog.
• Hosting Decision: Teams should confer with the Office of Environmental Information (OEI) to decide on the hosting environment; OEI will assess whether a secure, reliable, cost-effective Cloud option exists for the application.

2. Iterative Development

Delivering incremental value in the form of working, tested software.

Teams develop systems within fast-paced, incremental iterations. Usually an iteration lasts between 1-2 weeks, but that time-box is determined by the project team. Each iteration results in tested, working, deployable system functionality that provides tangible value to the user. User stories contain all documentation and acceptance criteria necessary for each item delivered within an increment. The iteration backlogs also contain all technology spikes necessary to build out and support system architecture and establish system operating environments. These small, frequent releases of working software allow for user and stakeholder feedback early and often.

Deliverables

• Release Backlog: The repository for all upcoming work planned for a given release.
• Iteration Backlogs: The repository for all upcoming work planned for a given iteration.
• Definition of Done: A checklist of the types of work the team is expected to successfully complete by the end of the release, before its work can be declared potentially shippable. A bare-minimum definition of done should yield a complete slice of the product functionality, one that has been designed, built, integrated, tested and documented; it should also deliver validated customer value.
• Working Software: Developed, tested code that can be released as-is and provide immediate value to end users.

3. Supporting Operations

Teams should strive to implement automatic deployments through continuous delivery services or similar techniques. Security scans, regression tests, load tests and other required finalization steps for deployment should similarly be automated to streamline the deployment process.

At minimum, at each iteration boundary, the team and product owner must complete final acceptance testing and ensure that manual deployment routines perform as expected as well as that all necessary documentation is updated to reflect new system features, architecture and security changes. User and production staff training for deployed features should also occur at iteration boundaries as necessary. After each production deployment, security, operations and development team members are expected to conduct a team retrospective to address any issues that arose throughout the process and to modify future stories as needed to ensure system concerns are addressed.

Deliverables

• UAT/SIT Results: Documented results and acceptance from User Acceptance Testing (UAT) and System Integration Testing (SIT). This may be performed by a group outside of the development team.
• Accessibility & Section 508 Test Results: Documented results and acceptance from Accessibility and Section 508 testing. This may be performed by a group outside of the development team.
• Security Assessment
• Training and Deployment Plan